search for: debug_name

...ences in debug info deployment model, the apple tables are not directly applicable to other targets, so instead of trying to make them fit, we chose to go with the standard approach. I personally will have some time to work on this this quarter or two, and my plan is roughly the following: 1. add .debug_names support to llvm-dwarfdump via the DebugInfo library (to enable testing of the table generation) 2. add .debug_names generation support (not enabled by default) 3. add .debug_names support to lldb 4. validate all three things work together 5. hook up .debug_names to clang's -glldb flag. 6. add...

Hello all, I am implementing support for .debug_names section (which is introduced in DWARFv5 standard as replacement for .debug_pubnames and .debug_pubtypes). The question is: should usage of DWARF version 5 force generation of .debug_names instead of .debug_pubnames or we can make it just default behavior and provide user with the interface (cm...

Hello, I hope I will have time to help you with that. I discussed dwarfv5 .debug_names implementation with involved party from RH. Anyway even if can't help much could you keep me in the loop please? On 01/17/2018 07:13 PM, Pavel Labath via llvm-dev wrote: > Hello all, > > In <https://reviews.llvm.org/D41986#977215> it was brought up that > there are at least...

On Wed, 17 Jan 2018 17:13:36 +0100, Pavel Labath via lldb-dev wrote: > so I'm writing this email to see if there's anyone > else interested in this topic, and to try to synchronize our efforts. I am sure interested in DWARF-5 .debug_names. I wrote its producer+consumer for GDB (but not producing/using DW_IDX_DIE_offset as GDB cannot use it). > 1. add .debug_names support to llvm-dwarfdump via the DebugInfo > library (to enable testing of the table generation) FYI FSF binutils readelf can read .debug_names already for some...

...o it's a good time >> to recap what has been done here so far. I am happy to report that >> stages 1-3 (i.e. producer/consumer in llvm and integration with lldb) >> of my original plan are now complete with one caveat. > > Awesome! > >> The caveat is that the .debug_names section is presently not a full >> drop-in replacement for the .apple_*** sections. The reason for that >> is that there is no equivalent to the .apple_objc section (which links >> an objc class/category name to all of its methods). I did not >> implement that, because I d...

...#39;t > know if the indexes covered all of the compile units in the linked > file or only some of them (in case some of the object files were > compiled with the tables and some without). > > In light of that, I don't think it's worth trying to combine > .apple_objc with .debug_names in some way, and it would be much > simpler to just extend .debug_names with the necessary information. I > think the simplest way of achieving this (one which would require > least amount of standard-bending) is to take the index entry for the > objc class and add a special attribute...

Hello all, I am looking for feedback regarding implementation of the case folding algorithm for .debug_names hashes. Unlike the apple tables, the .debug_names hashes are computed from case-folded names (to enable case-insensitive lookups for languages where that makes sense). The dwarf5 document specifies that the case folding should be done according the the "Caseless matching" Section of the...

...kratochvil at redhat.com> wrote: > On Wed, 17 Jan 2018 17:13:36 +0100, Pavel Labath via lldb-dev wrote: >> so I'm writing this email to see if there's anyone >> else interested in this topic, and to try to synchronize our efforts. > > I am sure interested in DWARF-5 .debug_names. I wrote its producer+consumer > for GDB (but not producing/using DW_IDX_DIE_offset as GDB cannot use it). > > >> 1. add .debug_names support to llvm-dwarfdump via the DebugInfo >> library (to enable testing of the table generation) > > FYI FSF binutils readelf can read...

...ain, It's been nearly six months since my first email, so it's a good time to recap what has been done here so far. I am happy to report that stages 1-3 (i.e. producer/consumer in llvm and integration with lldb) of my original plan are now complete with one caveat. The caveat is that the .debug_names section is presently not a full drop-in replacement for the .apple_*** sections. The reason for that is that there is no equivalent to the .apple_objc section (which links an objc class/category name to all of its methods). I did not implement that, because I do not see a way to embed that kind o...

> On Jan 30, 2018, at 7:35 AM, Pavel Labath <labath at google.com> wrote: > > Hello all, > > I am looking for feedback regarding implementation of the case folding > algorithm for .debug_names hashes. > > Unlike the apple tables, the .debug_names hashes are computed from > case-folded names (to enable case-insensitive lookups for languages > where that makes sense). The dwarf5 document specifies that the case > folding should be done according the the "Caseless matc...

...bundling our efforts on this. Let me know what I can do if there's anything else I can help with. Cheers, Jonas > On 17 Jan 2018, at 16:40, Victor Leschuk <vleschuk at accesssoftek.com> wrote: > > Hello, I hope I will have time to help you with that. I discussed > dwarfv5 .debug_names implementation with involved party from RH. Anyway > even if can't help much could you keep me in the loop please? > > > On 01/17/2018 07:13 PM, Pavel Labath via llvm-dev wrote: >> Hello all, >> >> In <https://reviews.llvm.org/D41986#977215> it was brough...

> On Jan 18, 2018, at 7:52 AM, Pavel Labath via lldb-dev <lldb-dev at lists.llvm.org> wrote: > > Thank you for all the responses. Unfortunately I wasn't able to make > any progress on creating the patches today. I'll be sure to add > everyone who expressed interest here to the phabricator diff once I > have them ready. > > Jonas, do you have any dsymutil

...at 15:41, Adrian Prantl <aprantl at apple.com> wrote: > > >> On Jan 30, 2018, at 7:35 AM, Pavel Labath <labath at google.com> wrote: >> >> Hello all, >> >> I am looking for feedback regarding implementation of the case folding >> algorithm for .debug_names hashes. >> >> Unlike the apple tables, the .debug_names hashes are computed from >> case-folded names (to enable case-insensitive lookups for languages >> where that makes sense). The dwarf5 document specifies that the case >> folding should be done according the the...

...evice *vgdev, cmd_p->capset_version = cpu_to_le32(version); *cache_p = cache_ent; virtio_gpu_queue_ctrl_buffer(vgdev, vbuf); - virtio_gpu_notify(vgdev); return 0; } @@ -922,7 +919,6 @@ void virtio_gpu_cmd_context_create(struct virtio_gpu_device *vgdev, uint32_t id, strncpy(cmd_p->debug_name, name, sizeof(cmd_p->debug_name) - 1); cmd_p->debug_name[sizeof(cmd_p->debug_name) - 1] = 0; virtio_gpu_queue_ctrl_buffer(vgdev, vbuf); - virtio_gpu_notify(vgdev); } void virtio_gpu_cmd_context_destroy(struct virtio_gpu_device *vgdev, @@ -937,7 +933,6 @@ void virtio_gpu_cmd_context...

...= cpu_to_le32(VIRTIO_GPU_CMD_GET_EDID); cmd_p->scanout = cpu_to_le32(scanout); virtio_gpu_queue_ctrl_buffer(vgdev, vbuf); + virtio_gpu_notify(vgdev); } return 0; @@ -924,6 +928,7 @@ void virtio_gpu_cmd_context_create(struct virtio_gpu_device *vgdev, uint32_t id, strncpy(cmd_p->debug_name, name, sizeof(cmd_p->debug_name) - 1); cmd_p->debug_name[sizeof(cmd_p->debug_name) - 1] = 0; virtio_gpu_queue_ctrl_buffer(vgdev, vbuf); + virtio_gpu_notify(vgdev); } void virtio_gpu_cmd_context_destroy(struct virtio_gpu_device *vgdev, @@ -938,6 +943,7 @@ void virtio_gpu_cmd_context...

...= cpu_to_le32(VIRTIO_GPU_CMD_GET_EDID); cmd_p->scanout = cpu_to_le32(scanout); virtio_gpu_queue_ctrl_buffer(vgdev, vbuf); + virtio_gpu_notify(vgdev); } return 0; @@ -924,6 +928,7 @@ void virtio_gpu_cmd_context_create(struct virtio_gpu_device *vgdev, uint32_t id, strncpy(cmd_p->debug_name, name, sizeof(cmd_p->debug_name) - 1); cmd_p->debug_name[sizeof(cmd_p->debug_name) - 1] = 0; virtio_gpu_queue_ctrl_buffer(vgdev, vbuf); + virtio_gpu_notify(vgdev); } void virtio_gpu_cmd_context_destroy(struct virtio_gpu_device *vgdev, @@ -938,6 +943,7 @@ void virtio_gpu_cmd_context...

...pecifically, the tool would do:   - Remove obsolete debug info which refers to code deleted by the linker     doing the garbage collection (gc-sections).   - Deduplicate debug type definitions for reducing resulting size of binary.   - Build accelerator/index tables.     = .debug_aranges, .debug_names, .gdb_index, .debug_pubnames, .debug_pubtypes.   - Strip unneeded tables.     = .debug_aranges, .debug_names, .gdb_index, .debug_pubnames, .debug_pubtypes.   - Compress or decompress debug info as requested. Possible feature:   - Join split dwarf .dwo files in a single file containing al...

...refers to code deleted by > the linker >      doing the garbage collection (gc-sections). > >    - Deduplicate debug type definitions for reducing resulting > size of > binary. > >    - Build accelerator/index tables. >      = .debug_aranges, .debug_names, .gdb_index, .debug_pubnames, > .debug_pubtypes. > >    - Strip unneeded tables. >      = .debug_aranges, .debug_names, .gdb_index, .debug_pubnames, > .debug_pubtypes. > >    - Compress or decompress debug info as requested. > > Possible feature:...

...refers to code deleted by > the linker >      doing the garbage collection (gc-sections). > >    - Deduplicate debug type definitions for reducing resulting > size of > binary. > >    - Build accelerator/index tables. >      = .debug_aranges, .debug_names, .gdb_index, .debug_pubnames, > .debug_pubtypes. > >    - Strip unneeded tables. >      = .debug_aranges, .debug_names, .gdb_index, .debug_pubnames, > .debug_pubtypes. > >    - Compress or decompress debug info as requested. > > Possible feature:...

...bigger than the usual linking time. Linking clang binary with DWARFLinker takes 72 sec, linking with the only lld takes 9 sec. 2. "Removing obsolete debug info" could not be switched off. Thus, lld could not use DWARFLinker for other tasks(like generation of index tables - .gdb_index, .debug_names) without significant performance degradation. 3. DWARFLinker does not support split dwarf at the moment. All these reasons are not blockers. And I believe implementation from D74169 might be integrated and incrementally improved if there would be agreement on that. Using DWARFLinker from llvm...