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 78962385C426; Sun, 31 May 2020 22:11:42 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org 78962385C426 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 566FE30278BD; Mon, 1 Jun 2020 00:11:41 +0200 (CEST) Received: by librem (Postfix, from userid 1000) id A71ABC03A6; Mon, 1 Jun 2020 00:11:11 +0200 (CEST) Date: Mon, 1 Jun 2020 00:11:11 +0200 From: Mark Wielaard To: Fangrui Song Cc: gdb@sourceware.org, elfutils-devel@sourceware.org, binutils@sourceware.org Subject: Re: Range lists, zero-length functions, linker gc Message-ID: <20200531221111.GL44629@wildebeest.org> References: <20200531185506.mp2idyczc4thye4h@google.com> <20200531201016.GJ44629@wildebeest.org> <20200531204738.xhyuemuaygi5ihdd@google.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20200531204738.xhyuemuaygi5ihdd@google.com> User-Agent: Mutt/1.10.1 (2018-07-13) X-Spam-Status: No, score=-5.1 required=5.0 tests=BAYES_00, JMQ_SPF_NEUTRAL, KAM_DMARC_STATUS, KAM_SHORT, 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:11:44 -0000 Hi, On Sun, May 31, 2020 at 01:47:38PM -0700, Fangrui Song via Elfutils-devel wrote: > On 2020-05-31, Mark Wielaard wrote: > > 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. > > I would love if we could solve the problem using ELF features, but > putting DW_TAG_subprogram in the same section group is not an > unqualified win Sorry for pushing back a little, but as a DWARF consumer this feels a little like the DWARF producer hasn't tried hard enough to produce valid DWARF and now tries to pass the problems off onto the DWARF consumer. Or when looking at it from the perspective of the linker, the compiler gave it an impossible problem to solve because it didn't really get all the pieces of the puzzle (the compiler already fused some independent parts together). I certainly appreciate the issue on 32-bit systems. It seems we already have reached the limits for some programs to be linked (or produce all the debuginfo) when all you got is 32-bits. But maybe that means that the problem is actually that the compiler already produced too much code/data. And the issue really is that it passes some problems, like unused code elimination, off to the linker. While the compiler really should have a better view of that, and should do that job itself. If it did, then it would never even produce the debuginfo in the first place. GCC used to produce horrible DWARF years ago with early LTO implementations, because they just handed it all off to the linker to figure out. But they solved it by generating DWARF in phases, only when it was known the DWARF was valid/consistent did it get produced. So that if some code was actually eliminated then the linker never even see any "code ranges" for code that disappeared. See Early Debug: https://gcc.gnu.org/wiki/early-debug Might some similar technique, where the compiler does a bit more work, so that it actually produces less DWARF to be processed by the linker, be used here? Sorry for pushing the problem back to the producer side, but as a consumer I think that is the more correct place to solve this. Cheers, Mark