From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-pf1-x434.google.com (mail-pf1-x434.google.com [IPv6:2607:f8b0:4864:20::434]) by sourceware.org (Postfix) with ESMTPS id 70146386F477 for ; Tue, 9 Jun 2020 20:24:19 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org 70146386F477 Received: by mail-pf1-x434.google.com with SMTP id b5so56146pfp.9 for ; Tue, 09 Jun 2020 13:24:19 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to; bh=KhTCPG4hGn0qdkLWLLcbjwYOupUlZxwm2c+5rALRrNA=; b=EhkNsQvqqpa6sUriTJkh5y82pUYO4X9SbdNbAUTCq1UTBryOOIqW+BvIma542JvQhk DNUZCDxtY/fVoBa00n13x2g9XBPFVpv/EYuGnzgHv4Z7SqCB3bZfbUt0paVW5nigvZbh yWNrQf3g90l171YNBSiIXhXokk5Cqend+Rm7Eq1pN+pZ4P+6hLx5jaTinj5iag0CQLFs Mocpa7lOJJ7iXNhhBmfQ5Dgqu2ZEd9jxjUuxd2sss8W/ttGnux802PFEC6tjRVv68Ovm U9Fb6By4f0N0oG5GhKkEIBaYhPqrTDEUbm6VzExR3LN8so4/A6QWhRntMpEfNPx0fm15 SVzA== X-Gm-Message-State: AOAM5327rzSbx4IadMouP/kahPZN9pyDWdcg/PEDWH4CSE7hAsXtO7gM wXQwgTeJExLMADQWkXVrfPvJ3nDleTnyHg== X-Google-Smtp-Source: ABdhPJxEJf3ICn34fr3j9w6X93H0ltSaqXz46DTh2WURGysGsLQg2EKaI18bZ3bYDxLYHTJc0y7V+Q== X-Received: by 2002:a63:205d:: with SMTP id r29mr26082543pgm.367.1591734258250; Tue, 09 Jun 2020 13:24:18 -0700 (PDT) Received: from google.com ([2620:15c:2ce:0:9efe:9f1:9267:2b27]) by smtp.gmail.com with ESMTPSA id k18sm10673178pfp.208.2020.06.09.13.24.17 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 09 Jun 2020 13:24:17 -0700 (PDT) Date: Tue, 9 Jun 2020 13:24:14 -0700 From: Fangrui Song To: gdb@sourceware.org, elfutils-devel@sourceware.org, binutils@sourceware.org Cc: Alan Modra , Mark Wielaard , David Blaikie Subject: Tombstone values in debug sections (was: Range lists, zero-length functions, linker gc) Message-ID: <20200609202414.2olgwq2jniweeyr6@google.com> References: <20200531201016.GJ44629@wildebeest.org> <20200531222937.GM44629@wildebeest.org> <20200601093103.GN44629@wildebeest.org> <20200603031040.GD29024@bubble.grove.modra.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Disposition: inline In-Reply-To: X-Spam-Status: No, score=-21.3 required=5.0 tests=BAYES_00, DKIMWL_WL_MED, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, ENV_AND_HDR_SPF_MATCH, RCVD_IN_DNSWL_NONE, SPF_HELO_NONE, SPF_PASS, TXREP, USER_IN_DEF_DKIM_WL, USER_IN_DEF_SPF_WL autolearn=ham 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: Tue, 09 Jun 2020 20:24:33 -0000 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). 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=200609.1 Some comments about the proposal: > - deduplicating different functions with identical content; GNU refers > to this as ICF (Identical Code Folding); ICF (gold --icf={safe,all}) can cause DW_TAG_subprogram with different DW_AT_name to have the same range. > - functions with no callers; sometimes called dead-stripping or > garbage collection. --gc-sections can lead to tombstone values. A referenced symbol may be discarded because its containing sections is garbage collected. > - functions emitted in COMDAT sections, typically C++ template > instantiations or inline functions from a header file; This can cause either tombstone values (STB_LOCAL) or duplicate DIEs (non-STB_LOCAL). On 2020-06-03, David Blaikie wrote: >On Tue, Jun 2, 2020 at 8:10 PM Alan Modra wrote: >> >> On Tue, Jun 02, 2020 at 11:06:10AM -0700, David Blaikie via Binutils wrote: >> > On Tue, Jun 2, 2020 at 9:50 AM Mark Wielaard wrote: >> > > where I >> > > would argue the compiler simply needs to make sure that if it generates >> > > code in separate sections it also should create the DWARF separate >> > > section (groups). >> > >> > I don't think that's practical - the overhead, I believe, is too high. >> > Headers for each section contribution (ELF headers but DWARF headers >> > moreso - having a separate .debug_addr, .debug_line, etc section for >> > each function would be very expensive) would make for very large >> > object files. >> >> With a little linker magic I don't see the neccesity of duplicating >> the DWARF headers. Taking .debug_line as an example, a compiler could >> emit the header, opcode, directory and file tables to a .debug_line >> section with line statements for function foo emitted to >> .debug_line.foo and for bar to .debug_line.bar, trusting that the >> linker will combine these sections in order to create an output >> .debug_line section. If foo code is excluded then .debug_line.foo >> info will also be dropped if section groups are used. > >I don't think this would apply to debug_addr - where the entries are >referenced from elsewhere via index, or debug_rnglist where the >rnglist header (or the debug_info directly) contains offsets into this >section, so taking chunks out would break those offsets. (or to the >file/directory name part of debug_line - where you might want to >remove file/line entries that were eliminated as dead code - but >that'd throw off the indexes)