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 8CD15385DC00; Sun, 31 May 2020 22:30:08 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org 8CD15385DC00 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 (ip4da7790f.direct-adsl.nl [77.167.121.15]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by gnu.wildebeest.org (Postfix) with ESMTPSA id 203C030278BD; Mon, 1 Jun 2020 00:30:06 +0200 (CEST) Received: by librem (Postfix, from userid 1000) id 71593C03A6; Mon, 1 Jun 2020 00:29:37 +0200 (CEST) Date: Mon, 1 Jun 2020 00:29:37 +0200 From: Mark Wielaard To: David Blaikie Cc: Fangrui Song , gdb@sourceware.org, elfutils-devel@sourceware.org, binutils@sourceware.org Subject: Re: Range lists, zero-length functions, linker gc Message-ID: <20200531222937.GM44629@wildebeest.org> References: <20200531185506.mp2idyczc4thye4h@google.com> <20200531201016.GJ44629@wildebeest.org> 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-Spam-Status: No, score=-5.0 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: Sun, 31 May 2020 22:30:09 -0000 Hi, On Sun, May 31, 2020 at 01:49:12PM -0700, David Blaikie wrote: > On Sun, May 31, 2020 at 1:41 PM Mark Wielaard wrote: > > On Sun, May 31, 2020 at 11:55:06AM -0700, Fangrui Song via Elfutils-devel wrote: > > > I am eager to know what you think > > > of the ideas from binutils/gdb/elfutils's perspective. > > > > I think this is a producer problem. If a (code) section can be totally > > dropped then the associated (.debug) sections should have been > > generated together with that (code) section in a COMDAT group. That > > way when the linker drops that section, all the associated sections in > > that COMDAT group will get dropped with it. If you don't do that, then > > the DWARF is malformed and there is not much a consumer can do about > > it. > > > > Said otherwise, I don't think it is correct for the linker (with > > --gc-sections) to drop any sections that have references to it > > (through relocation symbols) from other (.debug) sections. > > That's probably not practical for at least some users - the > easiest/most thorough counter-example is Split DWARF - the DWARF is in > another file the linker can't see. All the linker sees is a list of > addresses (debug_addr). I might be missing something, but I think this works fine with Split DWARF. As long as you make sure that the .dwo files/sections are separated along the same lines as the ELF section groups are. That means each section group either gets its own .dwo file, or you generate the .dwo sections in the same section group in the same object file using the SHF_EXCLUDED trick. That way each .debug.dwo uses their own index into the separate .debug_addr tables. If that group, with the .debug_addr table, gets discarded, then the reference to the .dwo also disappears and it simply won't be used. Cheers, Mark