From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from simark.ca by simark.ca with LMTP id uEMeMf+r+F8fNwAAWB0awg (envelope-from ) for ; Fri, 08 Jan 2021 14:01:19 -0500 Received: by simark.ca (Postfix, from userid 112) id C75881E99A; Fri, 8 Jan 2021 14:01:19 -0500 (EST) X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on simark.ca X-Spam-Level: X-Spam-Status: No, score=0.2 required=5.0 tests=DKIM_SIGNED,DKIM_VALID, DKIM_VALID_AU,MAILING_LIST_MULTI,RDNS_NONE,URIBL_BLOCKED autolearn=no autolearn_force=no version=3.4.2 Received: from sourceware.org (unknown [8.43.85.97]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by simark.ca (Postfix) with ESMTPS id 5ED2A1E590 for ; Fri, 8 Jan 2021 14:01:19 -0500 (EST) Received: from server2.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id 1283538438A3; Fri, 8 Jan 2021 19:01:19 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 1283538438A3 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sourceware.org; s=default; t=1610132479; bh=hTQNCZUhQppboBfIO0xXS3cc/OIzLFD8t3tCtMrSNCE=; h=References:In-Reply-To:Date:Subject:To:List-Id:List-Unsubscribe: List-Archive:List-Post:List-Help:List-Subscribe:From:Reply-To:Cc: From; b=q/7H9zh2DdmJX5rwg2EzBxT00Y6u9gjUDFrHcsvFYIClCVbR0hIrWDk8VOs4UJjNE MAjja1Os7c9nYQIpZ5QUx2SnlZQNRjENHvhvFy1qwPGybDZg5MsxTs4aXYS8xKzXI/ 6cvzzmQx+WN2YBMAfLT39G9WuwPVY8cbuMTqSnNI= Received: from mail-il1-x130.google.com (mail-il1-x130.google.com [IPv6:2607:f8b0:4864:20::130]) by sourceware.org (Postfix) with ESMTPS id E7A7D38438A3 for ; Fri, 8 Jan 2021 19:01:14 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org E7A7D38438A3 Received: by mail-il1-x130.google.com with SMTP id q1so11282490ilt.6 for ; Fri, 08 Jan 2021 11:01:14 -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=83keYH2VGHQdbnDfCQs9uTr2Y8BMUahcaWcMzu8CmPQ=; b=sy/cZiT/xNW/LbLwAHAHmPWqQGkMWz6aaI6iESSk7qaKI0uJ88WdHa7rDEO/nhyyLA HhzwS5108Bds2nWXnmAGAKpP7KgIO2qmWDbY3nKTRGgQwQWG+LIVHmw71KnI2uHofmQm f89S65swg8kZPAAGeACaQPkWen+/m5NRmHJm9DH4pW2ALODBFzMRPg5URoYpptivgizP HzF22cTSo/pFTowzt3nqdZTekTzNyBMVeVt687/sbkXsnc2/uokT751TmEUFVhHxJMDJ lw7pmt/bLzWgDvlRVxFgUlBPr0jZEGJFt7qvRQ9BF9YpC8YcCCaGhNziGw2PkrKdR7Y+ gP0g== X-Gm-Message-State: AOAM532Gyvm5XHG9r3UZtwsfZxcQl8ZeMoLbZChQFuubjLpChV5jAnu6 Fqfrlx63oqyx5dZR4nLF4tcKjjrvFYU1KgQ0h+4= X-Google-Smtp-Source: ABdhPJxcAeVvg3JMX+EwBXbeRE0e0XU3TpajfdQ5E2ooMv1efMpKpSw04Kx+JpM+dNwsi1y6WCuYFgTcpsos1Dw8lCQ= X-Received: by 2002:a92:9eda:: with SMTP id s87mr5335981ilk.85.1610132474427; Fri, 08 Jan 2021 11:01:14 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: Date: Fri, 8 Jan 2021 11:01:02 -0800 Message-ID: Subject: Re: GDB and debug fission To: Alexander Yermolovich 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: , From: David Blaikie via Gdb Reply-To: David Blaikie Cc: "gdb@sourceware.org" Errors-To: gdb-bounces@sourceware.org Sender: "Gdb" On Fri, Jan 8, 2021 at 10:52 AM Alexander Yermolovich 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 > *Sent:* Thursday, January 7, 2021 7:16 PM > *To:* Alexander Yermolovich > *Cc:* Sterling Augustine ; 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 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 > >