Re: GDB and debug fission

[David Blaikie via Gdb <gdb@sourceware.org>]

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
>