Re: GDB and debug fission

[David Blaikie <dblaikie@gmail.com>]

On Fri, Jan 8, 2021 at 10:52 AM Alexander Yermolovich <ayermolo@fb.com>
wrote:

> Thanks for the thorough response!
> I will keep your findings about incomplete gdb_index in mind.
> I think I saw a patch for LLD that would have not relied on pubnames, but
> I don't believe it landed.
>

Yeah, I think it was proposed - but that wouldn't help with Split DWARF,
because the linker wouldn't have access to the DWARF to reconstruct the
index/names from (since they'd be in the dwo files) - only relevant to
non-split gdb-index creation.


> Quickly looking at current code for gdb_index construction it uses
> pubnames from object files.
>
> Alex.
> ------------------------------
> *From:* David Blaikie <dblaikie@gmail.com>
> *Sent:* Thursday, January 7, 2021 7:16 PM
> *To:* Alexander Yermolovich <ayermolo@fb.com>
> *Cc:* Sterling Augustine <saugustine@google.com>; gdb@sourceware.org <
> gdb@sourceware.org>
> *Subject:* Re: GDB and debug fission
>
>
>
> On Thu, Jan 7, 2021 at 6:13 PM Alexander Yermolovich via Gdb <
> gdb@sourceware.org> wrote:
>
> Thanks for clarification.
> Yep I saw LLD builds gdb_index using gnu-pubnames. It just wasn't clear to
> me if gdb needs it with split-dwarf. I saw a comment on one of llvm reviews
> from couple years ago about it, but things might have changed since then.
> So thought I would ask. 🙂
>
> Without gdb_index and gnu_pubnames what will be the behavior of gdb?
> I tried a toy example locally with split-dwarf without gdb_index and
> pubnames and it seemed to work with binary compiled with -O2 and -g2.
> By work I mean I was able to step through code and print same variables as
> when I compiled it with monolithic debug information.
>
>
> Hmm - so far, I haven't been able to reproduce the failures I've seen in
> the past - it's possible I've made mistakes in the past and promoted the
> idea that gdb requires an index when using Split DWARF.
>
> What /does/ seem to be the case is that if you do create a gdb-index, it
> must be comprehensive - you must have built all your objects (that have
> DWARF) with -ggnu-pubnames, because it looks like gdb is assuming the index
> is comprehensive.
>
> Here's my example:
>
> $ cat a.cpp
>
> struct t1 { int x; };
>
> void a() {
>
>   t1 v1 = {3};
>
> }
>
> $ cat b.cpp
>
> void a();
>
> int main() {
>
>   a();
>
> }
>
> $ clang++ a.cpp b.cpp -gsplit-dwarf -g -gno-pubnames
>
> $ gdb --batch -ex "ptype t1" ./a.out
>
> ...
>
> type = struct t1 {
>
>     int x;
>
> }
>
> Aborted
>
> $ clang++ a.cpp b.cpp -gsplit-dwarf -g -Wl,--gdb-index -fuse-ld=lld
>
> $ gdb --batch -ex "ptype t1" ./a.out
>
> ...
>
> type = struct t1 {
>
>     int x;
>
> }
>
> Aborted
>
> $ clang++ a.cpp b.cpp -gsplit-dwarf -g -gno-pubnames -Wl,--gdb-index
> -fuse-ld=lld
>
> $ gdb --batch -ex "ptype t1" ./a.out
>
> ...
>
> No symbol "t1" in current context.
>
> And just for some added complexity... let's check if gdb can appropriately
> respect DW_AT_GNU_pubnames on CUs without an index.
>
> Hmm, seems it doesn't (or, at least, it doesn't worry about
> DW_AT_GNU_pubnames, perhaps it relies on checking the contents of the
> debug_gnu_pubnames/pubtypes section to see which units are covered by
> names? Or it's ignoring the contents entirely... - would have to hand-craft
> a dodgy debug_gnu_pub* section to test whether it's using it at all)
>
> (expanding/modifying the above example with 3 "external" files (so there's
> no risk gdb accidentally parsed them when parsing the main function, for
> instance) and 3 types)
>
> $ clang++ -gsplit-dwarf -ggnu-pubnames -g b.cpp c.cpp -c
> $ llvm-objcopy --remove-section=.debug_gnu_pubnames
> --remove-section=.debug_gnu_pubtypes c.o
> $ clang++ -gsplit-dwarf -g -gno-pubnames d.cpp -c
> $ clang++ a.cpp b.o c.o d.o -g
>
> $ gdb --batch -ex "ptype at" -ex "ptype bt" -ex "ptype ct" ./a.out
>
> ...
>
> type = struct at {
>
>     int i;
>
> }
>
> type = struct bt {
>
>     int i;
>
> }
>
> type = struct ct {
>
>     int i;
>
> }
>
> Aborted
>
> Let's try that hand-crafted/corrupt pubnames.
>
> Hmm, looks like gdb didn't care about my pubnames?
>
> $ llvm-dwarfdump-tot a.out -debug-gnu-pubtypes
>
> a.out:  file format elf64-x86-64
>
>
> .debug_gnu_pubtypes contents:
>
> length = 0x00000017, format = DWARF32, version = 0x0002, unit_offset =
> 0x00000000, unit_size = 0x00000030
>
> Offset     Linkage  Kind     Name
>
> 0x00000041 STATIC   TYPE     "int"
>
> length = 0x0000001f, format = DWARF32, version = 0x0002, unit_offset =
> 0x00000030, unit_size = 0x00000030
>
> Offset     Linkage  Kind     Name
>
> 0x00000031 EXTERNAL TYPE     "at"
>
> 0x00000041 STATIC   TYPE     "int"
>
> length = 0x00000017, format = DWARF32, version = 0x0002, unit_offset =
> 0x00000060, unit_size = 0x00000030
>
> Offset     Linkage  Kind     Name
> <<<<<<<<<<<<<< hand modified to remove "bt" here >>>>>>>>>>
>
> 0x00000028 STATIC   TYPE     "int"
>
> length = 0x0000001f, format = DWARF32, version = 0x0002, unit_offset =
> 0x00000090, unit_size = 0x00000030
>
> Offset     Linkage  Kind     Name
>
> 0x00000031 EXTERNAL TYPE     "ct"
>
> 0x00000041 STATIC   TYPE     "int"
>
> $ gdb --batch -ex "ptype at" -ex "ptype bt" -ex "ptype ct" ./a.out
>
> Unable to determine compiler version.
>
> Skipping loading of libstdc++ pretty-printers for now.
>
> Loading libc++ pretty-printers.
>
> Non-google3 binary detected.
>
> type = struct at {
>
>     int i;
>
> }
> <<<<<<<<<< gdb still manages to find bt >>>>>>>>>>>
>
> type = struct bt {
>
>     int i;
>
> }
>
> type = struct ct {
>
>     int i;
>
> }
>
> Aborted
>
> So based on all that, I /think/ the answer is:
>
> If you are going to use a linker-generated gdb-index with Split DWARF,
> then you must have gnu-pubnames on every input file. (because it can't
> build indexes for CUs without pubnames because it doesn't have access to
> the unit contents (because they're split) - in non-split cases, 'gold' will
> build the index itself by parsing the DWARF, I don't think 'lld' can do
> that, so if you're using lld, this advice applies to non-split DWARF too
> (either index everything, or don't have an index))
> But you'll have a really slow debugging experience if you don't do that -
> but, so far as I can tell, it looks like it'll be correct, just slow.
>
> But I'm super not sure about all of this. The "gdb only handles Split
> DWARF with an index" may be rumor, rumor that I accidentally promoted as
> fact based on some misunderstandings/incomplete experiments. Or maybe
> there's some truth to it I don't know how to reproduce...
>
> - Dave
>
>
> Thank You
> Alex
>
> ________________________________
> From: Sterling Augustine <saugustine@google.com>
> Sent: Thursday, January 7, 2021 5:48 PM
> To: Alexander Yermolovich <ayermolo@fb.com>
> Cc: gdb@sourceware.org <gdb@sourceware.org>
> Subject: Re: GDB and debug fission
>
> On Thu, Jan 7, 2021 at 5:25 PM Alexander Yermolovich via Gdb
> <gdb@sourceware.org> wrote:
> >
> > Hello.
> >
> > For latest gdb to work with -gsplit-dwarf debug information generated by
> clang, either in split or single mode does it need gdb_index or pubnames?
> > In normal case where debug information is part of executable gdb_index
> is nice to speed up startup time, and I think I read pubnames is not used,
> but with debug fission are either gdb_index or pubnames necessary?
>
> For gdb to work with split-dwarf debug info, it needs a gdb_index.
> That can be generated in several ways. Gdb can build one itself--there
> is a script somewhere to add a gdb index.
>
> But it is somewhat easier to have the linker you use generate
> gdb_index for you (both gnu-ld and llvm's lld can do this). They do
> this by reading the .gnu_pubnames section, so in some way, you need
> both pubnames *and* an index.
>
> So you would ordinarily use the following commands:
>
> $(CC) $(normal_arguments) -ggnu-pubnames
> $(LD)  $(normal_arguments) -Wl,--gdb-index
>
>