From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from simark.ca by simark.ca with LMTP id MLFsFsnRrl+QeQAAWB0awg (envelope-from ) for ; Fri, 13 Nov 2020 13:34:49 -0500 Received: by simark.ca (Postfix, from userid 112) id 59DB01F08B; Fri, 13 Nov 2020 13:34:49 -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.0 required=5.0 tests=MAILING_LIST_MULTI 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 592041EFBB for ; Fri, 13 Nov 2020 13:34:48 -0500 (EST) Received: from server2.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id A9B8A394CC10; Fri, 13 Nov 2020 18:34:47 +0000 (GMT) Received: from gnu.wildebeest.org (wildebeest.demon.nl [212.238.236.112]) by sourceware.org (Postfix) with ESMTPS id 83D52386F41C; Fri, 13 Nov 2020 18:34:44 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org 83D52386F41C Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=klomp.org Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=mark@klomp.org Received: from tarox.wildebeest.org (tarox.wildebeest.org [172.31.17.39]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by gnu.wildebeest.org (Postfix) with ESMTPSA id 68EE1300BF3A; Fri, 13 Nov 2020 19:34:43 +0100 (CET) Received: by tarox.wildebeest.org (Postfix, from userid 1000) id 23D2E40C9D80; Fri, 13 Nov 2020 19:34:43 +0100 (CET) Message-ID: <0f175f575fcf3172a1cc8e34ba9ac1b24803481e.camel@klomp.org> Subject: Re: Split DWARF and rnglists, gcc vs clang From: Mark Wielaard To: Simon Marchi Date: Fri, 13 Nov 2020 19:34:43 +0100 In-Reply-To: References: <20201113001143.GA2654@wildebeest.org> <3a747adc-af41-7492-de36-b357e5429fff@polymtl.ca> <55c0f2f69f1e6ad5d008665d004d629ad62ab65f.camel@klomp.org> Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Evolution 3.28.5 (3.28.5-10.el7) Mime-Version: 1.0 X-BeenThere: gdb-patches@sourceware.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Gdb-patches mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: "gdb@sourceware.org" , "gdb-patches@sourceware.org" , gcc@gcc.gnu.org Errors-To: gdb-patches-bounces@sourceware.org Sender: "Gdb-patches" Hi Simon, On Fri, 2020-11-13 at 10:41 -0500, Simon Marchi wrote: > So in the end the logical thing to do when encountering a > DW_FORM_rnglistx in a split-unit, in order to support everybody, is > probably to go to the .debug_rnglists.dwo section, if there's one, > disregarding the (inherited) DW_AT_rnglists_base. If there isn't, then > try the linked file's .debug_rnglists section, using > DW_AT_rnglists_base. If there isn't, then something is malformed. Yes, I think that makes sense. > > I interpreted it as when there is a base attribute in the (skeleton) > > unit, then the corresponding section (index table) can be found in the > > main object file. >=20 > That doesn't work with how clang produces it, AFAIU. There is a > DW_AT_rnglists_base attribute in the skeleton and a .debug_rnglists in > the linked file, which is used for the skeleton's DW_AT_ranges > attribute. And there is also .debug_rnglists.dwo sections in the DWO > files. So DW_FORM_rnglistx values in the skeleton use the > .debug_rnglists in the linked file, while the DW_FORM_rnglistx values > in the DWO file use the .debug_rnglists.dwo in that file (even though > there is a DW_AT_rnglists_base in the skeleton). I would have expected the skeleton's DW_AT_ranges to use DW_FORM_secoffset, not DW_FORM_rnglistx. Precisely because you would then get an ambiguity. But it would indeed be good to handle that situation. > > I think it depends on who exactly you ask and what their specific > > goals/setups are. Both things, reducing the number of relocations and > > moving data out of the main object file, are independently useful in > > different context. But I think it is mainly reducing the number of > > relocations that is beneficial. For example clang (but not yet gcc) > > supports having the .dwo sections themselves in the main object file > > (using SHF_EXCLUDED for the .dwo sections, so the linker will still > > skip them). Which is also a possibility that the spec describes and > > which really makes split DWARF much more usable, because then you don't > > need to change your build system to deal with multiple output files. >=20 > Not sure I understand. Does that mean that the .dwo sections are > emitted in the .o files, and that's the end of the road for them? The > DW_AT_dwo_name attributes of the skeletons then refer to the .o files? Yes, precisely. I am not sure whether it is already in any released clang, but if it is you could try -gsplit-dwarf=3Dsingle to see an example. Note that elfutils libdw doesn't yet handle that variant. Luckily not because of a design issue, but because there are some sanity checks that trigger when seeing a .debug_xxx and .debug_xxx.dwo section in the same file. I have a partial patch to fix that and make it so that you can explicitly open a file as either a "main" Dwarf or "split" Dwarf. The only thing it doesn't do yet is share the file handle between the Dwarf object (which isn't strictly needed, but would be a nice optimization). I actually think having a "single" split-dwarf file (.o =3D=3D .dwo) is the best way to support Split Dwarf more generically because then it would simply work without having to adjust all build systems to work with/around separate .dwo files. Cheers, Mark