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 E187D3858D34; Fri, 19 Jun 2020 20:04:52 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org E187D3858D34 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 04E1D3000C8B; Fri, 19 Jun 2020 22:04:50 +0200 (CEST) Received: by tarox.wildebeest.org (Postfix, from userid 1000) id D340A436ED17; Fri, 19 Jun 2020 22:04:50 +0200 (CEST) Message-ID: <69e4e7a60b23bff32d88b3edd2a718cf2f6e8cdc.camel@klomp.org> Subject: Re: Tombstone values in debug sections (was: Range lists, zero-length functions, linker gc) From: Mark Wielaard To: Fangrui Song , gdb@sourceware.org, elfutils-devel@sourceware.org, binutils@sourceware.org Cc: David Blaikie , Alan Modra Date: Fri, 19 Jun 2020 22:04:50 +0200 In-Reply-To: <20200609202414.2olgwq2jniweeyr6@google.com> References: <20200531201016.GJ44629@wildebeest.org> <20200531222937.GM44629@wildebeest.org> <20200601093103.GN44629@wildebeest.org> <20200603031040.GD29024@bubble.grove.modra.org> <20200609202414.2olgwq2jniweeyr6@google.com> Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Evolution 3.28.5 (3.28.5-8.el7) Mime-Version: 1.0 X-Spam-Status: No, score=-7.2 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: elfutils-devel@sourceware.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Elfutils-devel mailing list List-Unsubscribe: , List-Archive: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Jun 2020 20:04:54 -0000 Hi, On Tue, 2020-06-09 at 13:24 -0700, Fangrui Song via Elfutils-devel wrote: > I want to revive the thread, but focus on whether a tombstone value > (-1/-2) in .debug_* can cause trouble to various DWARF consumers (gdb, > debug related tools in elfutils and other utilities I don't know about). >=20 > Paul Robinson has proposed that DWARF v6 should reserve a tombstone > value (the value a relocation referencing a discarded symbol in a > .debug_* section should be resolved to) > http://www.dwarfstd.org/ShowIssue.php?issue=3D200609.1 I would appreciate having a clear "not valid" marker instead of getting a possibly bogus (but valid) address. -1 seems a reasonable value. Although I have seen (and written) code that simply assumes zero is that value. Would such an invalid address marker in an DW_AT_low_pc make the whole program scope under a DIE invalid? What about (addr, loc, rng) base addresses? Can they contain an invalid marker, does that make the whole table/range invalid? I must admit that as a DWARF consumer I am slightly worried that having a sanctioned "invalid marker" will cause DWARF producers to just not coordinate and simply assume they can always invalidate anything they emit. Even if there could be a real solution by coordinating between compiler/linker who is responsible for producing the valid DWARF entries (especially when LTO is involved). > Some comments about the proposal: >=20 > > - deduplicating different functions with identical content; GNU > > refers > > to this as ICF (Identical Code Folding); >=20 > ICF (gold --icf=3D{safe,all}) can cause DW_TAG_subprogram with > different DW_AT_name to have the same range. Cary Coutant wrote up a general Two-Level Line Number Table proposal to address the issue of having a single machine instruction corresponds to more than one source statement: http://wiki.dwarfstd.org/index.php?title=3DTwoLevelLineTables Which seems useful in these kind of situations. But I don't know the current status of the proposal. Cheers, Mark