From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from gnu.wildebeest.org (wildebeest.demon.nl [212.238.236.112]) by sourceware.org (Postfix) with ESMTPS id 87CC23857021; Fri, 13 Nov 2020 15:18:21 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org 87CC23857021 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 730A93009852; Fri, 13 Nov 2020 16:18:20 +0100 (CET) Received: by tarox.wildebeest.org (Postfix, from userid 1000) id 2658C400141E; Fri, 13 Nov 2020 16:18:20 +0100 (CET) Message-ID: <55c0f2f69f1e6ad5d008665d004d629ad62ab65f.camel@klomp.org> Subject: Re: Split DWARF and rnglists, gcc vs clang From: Mark Wielaard To: Simon Marchi Cc: "gdb@sourceware.org" , gcc@gcc.gnu.org, "gdb-patches@sourceware.org" Date: Fri, 13 Nov 2020 16:18:19 +0100 In-Reply-To: <3a747adc-af41-7492-de36-b357e5429fff@polymtl.ca> References: <20201113001143.GA2654@wildebeest.org> <3a747adc-af41-7492-de36-b357e5429fff@polymtl.ca> 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-Spam-Status: No, score=-5.5 required=5.0 tests=BAYES_00, JMQ_SPF_NEUTRAL, KAM_DMARC_STATUS, SPF_HELO_NONE, SPF_PASS, TXREP autolearn=no autolearn_force=no version=3.4.2 X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on server2.sourceware.org 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: Fri, 13 Nov 2020 15:18:23 -0000 Hi Simon, On Fri, 2020-11-13 at 09:45 -0500, Simon Marchi wrote: > I think I would have asked the question the other way around :) The > > spec explicitly describes rnglists_base (and loclists_base) as a way > > to reference ranges (loclists) through the index table, so that the > > only relocation you need is in the (skeleton) DIE. >=20 > I presume you reference this non-normative text in section 2.17.3? >=20 > This range list representation, the rnglist class, and the related > DW_AT_rnglists_base attribute are new in DWARF Version 5. Together > they eliminate most or all of the object language relocations > previously needed for range lists. That too, but I was actually referring to the sections that define Range List and Location List Tables (7.28 and 7.29) which define the meaning of DW_AT_rnglists_base and DW_AT_loclists_base. But you could also look at 3.1.3 Split Full Compilation Unit Entries which says that those base attributes are inherited from the corresponding skeleton compilation unit for a split unit. > What I understand from this is that the rnglist class and > DW_AT_rnglists_base attribute help reduce the number of relocations in > the non-split case (it removes the need for relocations from > DW_AT_ranges attribute values in .debug_info to .debug_rnglists). I > don't understand it as saying anything about where to put the rnglist > data in the split-unit case. 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. At least that is how elfutils libdw interprets the base attributes, not just for rnglists_base, but also str_offsets_base, addr_base, etc. And that is also how/when GCC emits them. > > So I believe both encodings are valid according to the spec. It just > > depends on what you are optimizing for, small main object file size or > > smallest encoding with least number of indirections. >=20 > So, if I understand correctly, gcc's way of doing things (putting all > the rnglists in a common .debug_rnglists section) reduces the overall > size of debug info since the rnglists can use the direct addressing > rnglists entries (e.g. DW_RLE_start_end) rather than the indirect ones > (e.g. DW_RLE_startx_endx). But this come at the expense of a lot of > relocations in the rnglists themselves, since they refer to addresses > directly. Yes, and it reduces the number of .debug_addr entries that need relocations. > I thought that the main point of split-units was to reduce the number of > relocations processed by the linker and data moved around by the linker, > to reduce link time and provide a better edit-build-debug cycle. Is > that the case? 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. > > P.S. I am really interested in these interpretations of DWARF, but I > > don't really follow the gdb implementation details very much. Could we > > maybe move discussions like these from the -patches list to the main > > gdb (or gcc) mailinglist? >=20 > Sure, I added gdb@ and gcc@. I also left gdb-patches@ so that it's > possible to follow the discussion there. Thanks, Mark