From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from simark.ca by simark.ca with LMTP id TI6VOnvPrV+0XQAAWB0awg (envelope-from ) for ; Thu, 12 Nov 2020 19:12:43 -0500 Received: by simark.ca (Postfix, from userid 112) id E2EF01F08B; Thu, 12 Nov 2020 19:12:43 -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 045101E58E for ; Thu, 12 Nov 2020 19:12:43 -0500 (EST) Received: from server2.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id 8FF5A3858024; Fri, 13 Nov 2020 00:12:42 +0000 (GMT) Received: from gnu.wildebeest.org (wildebeest.demon.nl [212.238.236.112]) by sourceware.org (Postfix) with ESMTPS id 8CE803858024 for ; Fri, 13 Nov 2020 00:12:40 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org 8CE803858024 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 librem (deer0x15.wildebeest.org [172.31.17.151]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by gnu.wildebeest.org (Postfix) with ESMTPSA id F270130291AB; Fri, 13 Nov 2020 01:12:38 +0100 (CET) Received: by librem (Postfix, from userid 1000) id 980CBC0EA1; Fri, 13 Nov 2020 01:11:43 +0100 (CET) Date: Fri, 13 Nov 2020 01:11:43 +0100 From: Mark Wielaard To: Simon Marchi Subject: Re: Split DWARF and rnglists, gcc vs clang Message-ID: <20201113001143.GA2654@wildebeest.org> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.10.1 (2018-07-13) 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-patches@sourceware.org Errors-To: gdb-patches-bounces@sourceware.org Sender: "Gdb-patches" Hi Simon, On Thu, Nov 05, 2020 at 11:11:43PM -0500, Simon Marchi wrote: > I'm currently squashing some bugs related to .debug_rnglists in GDB, and > I happened to notice that clang and gcc do different things when > generating rnglists with split DWARF. I'd like to know if the two > behaviors are acceptable, and therefore if we need to make GDB accept > both. Or maybe one of them is not doing things correctly and would need > to be fixed. > > clang generates a .debug_rnglists.dwo section in the .dwo file. Any > DW_FORM_rnglistx attribute in the DWO refers to that section. That > section is not shared with any other object, so DW_AT_rnglists_base is > never involved for these attributes. Note that there might still be a > DW_AT_rnglists_base on the DW_TAG_skeleton_unit, in the linked file, > used if the skeleton itself has an attribute of form DW_FORM_rnglistx. > This rnglist would be found in a .debug_rnglists section in the linked > file, shared with the other units of the linked file. > > gcc generates a single .debug_rnglists in the linked file and no > .debug_rnglists.dwo in the DWO files. So when an attribute has form > DW_FORM_rnglistx in a DWO file, I presume we need to do the lookup in > the .debug_rnglists section in the linked file, using the > DW_AT_rnglists_base attribute found in the corresponding skeleton unit. > This looks vaguely similar to how it was done pre-DWARF 5, with > DW_AT_GNU_ranges base. > > So, is gcc wrong here? I don't see anything in the DWARF 5 spec > prohibiting to do it like gcc does, but clang's way of doing it sounds > more in-line with the intent of what's described in the DWARF 5 spec. > So I wonder if it's maybe an oversight or a misunderstanding between the > two compilers. 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. But the rnglists (loclists) themselves can still use relocations. A large part of them is non-shared addresses, so using indexes (into the .debug_addr addr_base) would simply be extra overhead. The relocations will disappear once linked, but the index tables won't. As an alternative, if you like to minimize the amount of debug data in the main object file, the spec also describes how to put a whole .debug_rnglists.dwo (or .debug_loclists.dwo) in the split dwarf file. Then you cannot use all entry encodings and do need to use an .debug_addr index to refer to any addresses in that case. So the relocations are still there, you just refer to them through an extra index indirection. 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. Cheers, Mark 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?