[PATCH] D82367: [ObjectYAML][ELF] Add support for emitting the .debug_gnu_pubnames/pubtypes sections.

[David Blaikie via Phabricator via llvm-commits]

dblaikie added a comment.

In D82367#3135300 <https://reviews.llvm.org/D82367#3135300>, @clayborg wrote:

> In D82367#3135210 <https://reviews.llvm.org/D82367#3135210>, @dblaikie wrote:
>
>> In D82367#3133152 <https://reviews.llvm.org/D82367#3133152>, @clayborg wrote:
>>
>>> In D82367#3133132 <https://reviews.llvm.org/D82367#3133132>, @dblaikie wrote:
>>>
>>>> In D82367#3133081 <https://reviews.llvm.org/D82367#3133081>, @clayborg wrote:
>>>>
>>>>> Is ".debug_gnu_pubtypes" different and/or better than the old ".debug_pubtypes" in terms of contents? AFAIK all debuggers completely ignore these sections as they don't contain all types (only public types). I did a quick web search for ".debug_gnu_pubtypes" and didn't find any docs or anything documenting this format.
>>>>
>>>> My general understanding is that GCC/GDB folks implemented .debug_gnu_pubnames(/types) because of the lack of guarantees in debug_pubnames(/types) - GCC does consume/rely on these sections (& gold can produce .gdb_index from these gnu_pub* sections - which is /necessary/ for correctness of gdb when using Split DWARF, in fact).
>>>>
>>>> I'm guessing like lots of stuff, it's probably basically defined by the agreement between GCC and GDB - and Clang/LLVM just tries to implement gnu_pub* to be as compatible as possible with that.
>>>
>>> Was there any documentation on this where the contents of this new format are detailed?
>>
>> Not that I know of.
>>
>>> Sounds promising and I would love to have LLDB to not have to manually index DWARF on all linux/android targets if at all possible.
>>
>> Presumably LLDB should probably be looking at the newer .debug_names format that's been standardized/documented, and derived from the apple names accelerator tables.
>
> We have support already and we do look at that. Not many compilers enable DWARF5 at the moment, so we rarely see the .debug_names in any binaries, but LLDB is ready for these. It is hard to control and change the toolchains that people build with. My idea was to write a post processing tool that can add the .debug_names to binaries, like maybe llvm-objcopy or other tool.

Yep, a post-processing tool to add .debug_names could be nice. Given folks have to add extra flags to get gnu (or non-gnu) pubnames (-ggnu-pubnames in both GCC and Clang) with GCC and Clang - they could instead switch to DWARFv5 "just as easily" (not quite, but close) - though certainly the ecosystem issues if they need to support tools that can't consume DWARFv5, etc. (perhaps .debug_names could be supported in pre-v5 modes as a backwards/partial compatibility mode - rather than having to produce gnu_pubnames)

Though producing gnu_pubnames/plain pubnames and linking those into .debug_names in the linker wouldn't be a bad thing to support either (though maybe has the problem of "this doesn't have all the names it needs to have" which is the general problem with all this).


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D82367/new/

https://reviews.llvm.org/D82367