[PATCH] D82367: [ObjectYAML][ELF] Add support for emitting the .debug_gnu_pubnames/pubtypes sections.
David Blaikie via Phabricator via llvm-commits
llvm-commits at lists.llvm.org
Tue Nov 16 09:18:04 PST 2021
dblaikie added a comment.
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.
Repository:
rG LLVM Github Monorepo
CHANGES SINCE LAST ACTION
https://reviews.llvm.org/D82367/new/
https://reviews.llvm.org/D82367
More information about the llvm-commits
mailing list