From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-io1-xd35.google.com (mail-io1-xd35.google.com [IPv6:2607:f8b0:4864:20::d35]) by sourceware.org (Postfix) with ESMTPS id A3D28386F036 for ; Mon, 1 Feb 2021 20:15:08 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org A3D28386F036 Received: by mail-io1-xd35.google.com with SMTP id n14so4980496iog.3 for ; Mon, 01 Feb 2021 12:15:08 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=0uHKhUdwa1kkV/nPSLrBh3yKdcJohiKhN2c3tRrkir0=; b=ojBD8ySErMn+Sbh3CgwXhooXUg8UegMNnfBJ4wxkMQuhYRorryFt/gcQpHJlnlCkjV 38mWeEtvtDnJxM7mZPH5+6Xf07untdUbjxzHLm0bHX2Lp6x5dm58dhnUbGxVukoPwG04 pJXPTMpa1Zj++z8svdMAwYFxoKMyd3ImbbU2u83kKPAvfGgPLxc7kisGhSXZURTb7tb0 4AJJ6qFTe1Vm2qS+RruVMqIX5CclgLdQiyLV+WvSIeGSVwePtNig14hy6mxkvAY4szwi QJPsbsZyLZXhrQ+fxmZ55rDGxWIEQoQbkcswxrH9RFoQp9oa27mCBLJa+NRiDFgnG69q m8OQ== X-Gm-Message-State: AOAM532XXEQYE1PfkDgnBVwNcBmb5QMx1AUcrJ0LPpZuuZnV7l2uk2dc xLg9IsUjehrDMJDDaWm+AR5md+UDQnelm1c0KDE8+Al9 X-Google-Smtp-Source: ABdhPJzoDZI+fzZD1aQJ4+gxvUZSYhzutgutbGK1bBvtiDyglxD6+TuWi31codVdHxgLa+NOelZYIEt7cquo+3Z+mQk= X-Received: by 2002:a6b:9356:: with SMTP id v83mr2590570iod.78.1612210508149; Mon, 01 Feb 2021 12:15:08 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: David Blaikie Date: Mon, 1 Feb 2021 12:14:56 -0800 Message-ID: Subject: Re: GDB and debug fission To: Alexander Yermolovich Cc: Jorge Gorbe Moya , Sterling Augustine , "gdb@sourceware.org" X-Spam-Status: No, score=-2.3 required=5.0 tests=BAYES_00, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, FREEMAIL_FROM, HTML_MESSAGE, RCVD_IN_DNSWL_NONE, SPF_HELO_NONE, SPF_PASS, TXREP autolearn=ham autolearn_force=no version=3.4.2 X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on server2.sourceware.org Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.29 X-BeenThere: gdb@sourceware.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Gdb mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Feb 2021 20:15:11 -0000 Glad to hear you can reproduce this - so, yeah, there's at least one place where gdb has impaired behavior in the absence of an index when using split DWARF. On Mon, Feb 1, 2021 at 12:07 PM Alexander Yermolovich wrote: > I tried creating dwp, even without deleting dwo I see: > (gdb) ptype t1 > No symbol "t1" in current context. > (gdb) start > Temporary breakpoint 1 at 0x4005ca: file main.cpp, line 3. > Starting program: /data/users/ayermolo/tasks/T81935790/main > warning: Loadable section ".note.gnu.property" outside of ELF segments > warning: Loadable section ".note.gnu.property" outside of ELF segments > > Temporary breakpoint 1, main () at main.cpp:3 > 3 int main() { t1 v1; } > (gdb) ptype t1 > No symbol "t1" in current context. > > I guess it makes sense since I think gdb will just use dwp if it sees it > in same directory. > With -Wl,--gdb-index I see same behavior as you. Everything gets resovled= . > > I see same behavior with TOT clang. > > Alex > ------------------------------ > *From:* David Blaikie > *Sent:* Friday, January 29, 2021 5:06 PM > *To:* Alexander Yermolovich > *Cc:* Jorge Gorbe Moya ; Sterling Augustine < > saugustine@google.com>; gdb@sourceware.org > *Subject:* Re: GDB and debug fission > > Ah, you might need a dwp to reproduce this. Try building a dwp for the > .dwo and deleting the dwo? > > > > On Fri, Jan 29, 2021 at 4:42 PM Alexander Yermolovich > wrote: > > I tried it locally with: > > struct t1 { int x; }; > > int main() { t1 v1; } > Using your commands, but with g++ (GCC) 8.4.1 20200928 (Red Hat > 8.4.1-1)/gold and TOT clang++/lld. > GNU gdb (GDB) 9.1 > For me it was able to resolve t1. > Some kind of regression with TOT gcc? > > Alex > ------------------------------ > *From:* David Blaikie > *Sent:* Friday, January 29, 2021 12:34 PM > *To:* Alexander Yermolovich ; Jorge Gorbe Moya < > jgorbe@google.com> > *Cc:* Sterling Augustine ; gdb@sourceware.org < > gdb@sourceware.org> > *Subject:* Re: GDB and debug fission > > Well, I found one place where the index seems necessary: Type units: > > $ g++-tot a.cpp -fdebug-types-section -gdwarf-4 -gsplit-dwarf -c > $ g++-tot a.o -fuse-ld=3Dgold > $ gdb ./a.out > ... > (gdb) ptype t1 > No symbol "t1" in current context. > (gdb) start > Temporary breakpoint 1 at 0x401106: file a.cpp, line 3. > Starting program: /usr/local/google/home/blaikie/dev/scratch/a.out > > Temporary breakpoint 1, main () at a.cpp:3 > 3 int main() { t1 v1; } > (gdb) ptype t1 > type =3D const float > > But if you add -Wl,--gdb-index to the link command - it works correctly, > with t1 being found and rendered. > > On Thu, Jan 7, 2021 at 7:16 PM David Blaikie wrote: > > > > 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 t= o > me if gdb needs it with split-dwarf. I saw a comment on one of llvm revie= ws > from couple years ago about it, but things might have changed since then. > So thought I would ask. =F0=9F=99=82 > > 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 a= s > 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 ind= ex > is comprehensive. > > Here's my example: > > $ cat a.cpp > > struct t1 { int x; }; > > void a() { > > t1 v1 =3D {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 =3D struct t1 { > > int x; > > } > > Aborted > > $ clang++ a.cpp b.cpp -gsplit-dwarf -g -Wl,--gdb-index -fuse-ld=3Dlld > > $ gdb --batch -ex "ptype t1" ./a.out > > ... > > type =3D struct t1 { > > int x; > > } > > Aborted > > $ clang++ a.cpp b.cpp -gsplit-dwarf -g -gno-pubnames -Wl,--gdb-index > -fuse-ld=3Dlld > > $ 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 appropriatel= y > 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-cra= ft > 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=3D.debug_gnu_pubnames > --remove-section=3D.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 =3D struct at { > > int i; > > } > > type =3D struct bt { > > int i; > > } > > type =3D 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 =3D 0x00000017, format =3D DWARF32, version =3D 0x0002, unit_offse= t =3D > 0x00000000, unit_size =3D 0x00000030 > > Offset Linkage Kind Name > > 0x00000041 STATIC TYPE "int" > > length =3D 0x0000001f, format =3D DWARF32, version =3D 0x0002, unit_offse= t =3D > 0x00000030, unit_size =3D 0x00000030 > > Offset Linkage Kind Name > > 0x00000031 EXTERNAL TYPE "at" > > 0x00000041 STATIC TYPE "int" > > length =3D 0x00000017, format =3D DWARF32, version =3D 0x0002, unit_offse= t =3D > 0x00000060, unit_size =3D 0x00000030 > > Offset Linkage Kind Name > <<<<<<<<<<<<<< hand modified to remove "bt" here >>>>>>>>>> > > 0x00000028 STATIC TYPE "int" > > length =3D 0x0000001f, format =3D DWARF32, version =3D 0x0002, unit_offse= t =3D > 0x00000090, unit_size =3D 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 =3D struct at { > > int i; > > } > <<<<<<<<<< gdb still manages to find bt >>>>>>>>>>> > > type =3D struct bt { > > int i; > > } > > type =3D 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' wi= ll > 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 > Sent: Thursday, January 7, 2021 5:48 PM > To: Alexander Yermolovich > Cc: gdb@sourceware.org > Subject: Re: GDB and debug fission > > On Thu, Jan 7, 2021 at 5:25 PM Alexander Yermolovich via Gdb > wrote: > > > > Hello. > > > > For latest gdb to work with -gsplit-dwarf debug information generated b= y > 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 > >