From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from simark.ca by simark.ca with LMTP id QipVMLrO918RHgAAWB0awg (envelope-from ) for ; Thu, 07 Jan 2021 22:17:14 -0500 Received: by simark.ca (Postfix, from userid 112) id BA2D31E940; Thu, 7 Jan 2021 22:17:14 -0500 (EST) X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on simark.ca X-Spam-Level: X-Spam-Status: No, score=-1.1 required=5.0 tests=DKIM_SIGNED,DKIM_VALID, DKIM_VALID_AU,MAILING_LIST_MULTI,URIBL_BLOCKED autolearn=ham autolearn_force=no version=3.4.2 Received: from sourceware.org (server2.sourceware.org [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 8FA451E940 for ; Thu, 7 Jan 2021 22:17:13 -0500 (EST) Received: from server2.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id 138A03850401; Fri, 8 Jan 2021 03:17:13 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 138A03850401 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sourceware.org; s=default; t=1610075833; bh=z8vXxgcGnw2SEjCkpiQR43GldTK40o9fRg8i5kcsDXs=; 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=m9Fnx2Td1+F+tFtwDzXqGaKpYNqaw2bXIMmpxbzSYcFMcwX6k/b9y43vP0gz//Nm5 7Z+mz1+9GcQp1I0S8yVrevX4CkkQy/ZdIgGTomZhwrcVSQIPn2zsVxKhuhi8HPvbXW aFzRREb20vwtdE3VoTK5OI64Wena/4Ur87aa6BJY= Received: from mail-il1-x129.google.com (mail-il1-x129.google.com [IPv6:2607:f8b0:4864:20::129]) by sourceware.org (Postfix) with ESMTPS id 99A1E3850401 for ; Fri, 8 Jan 2021 03:17:09 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org 99A1E3850401 Received: by mail-il1-x129.google.com with SMTP id n9so8993273ili.0 for ; Thu, 07 Jan 2021 19:17:09 -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=Ll4iTC2jpYVdYCg9yDlodhRZvl+IvHQfN96sv8jo1J0=; b=ZBO6egqqs14FVhK/63oFpp7Cm5mHxLve1BvO/8f/fpzzFcMXTVgTC2FvaU8vQt6+19 O/UjobPF+pB8AfDGY4z+RpTXc+gE570tHbVE+/2V93wtDHDNVAD+tnEEVdyZa16N8teO uXacMhvO8ZArsDS7yk6A1ZN45iNVX0+D1VKDJLuar3stDSqgsMyWJbIB2zK2M/Av4ikS a/3oNrgqnZwVZMoqY7t/IKSeQzU+9zUEnX7R5v86+xqs0iOQalRuVyYYzthqnNaQmIID nEouwYWKbTwyxHadoG/7masrQUA9B1ffCB45wydYtD6dbbQU/M7qKEGGkY1XlsaZM1jL 6t1A== X-Gm-Message-State: AOAM532FgeWN3+HN/zD94I6XHeLgO4JYtof2KOA7CyUpxX30CHz3JpIc a05P8v+210sxpLiAhsSOM6ZIUMZ59cEUImQ0Az1TO23VXJw= X-Google-Smtp-Source: ABdhPJz+8i48kohVplh+NQq7adHRWHw/dwPowyacZu/tSLZnIujN9eWvm/mAmeoUz3paUsP1N/ZTd1EJrIR30ry3f/4= X-Received: by 2002:a05:6e02:13b2:: with SMTP id h18mr1944644ilo.197.1610075828903; Thu, 07 Jan 2021 19:17:08 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: Date: Thu, 7 Jan 2021 19:16:57 -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 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 index 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 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=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_offset = =3D 0x00000000, unit_size =3D 0x00000030 Offset Linkage Kind Name 0x00000041 STATIC TYPE "int" length =3D 0x0000001f, format =3D DWARF32, version =3D 0x0002, unit_offset = =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_offset = =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_offset = =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' 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 > 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 >