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 190163851C08; Sun, 31 May 2020 20:10:48 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org 190163851C08 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 22D8C30278BD; Sun, 31 May 2020 22:10:45 +0200 (CEST) Received: by librem (Postfix, from userid 1000) id 58122C3F24; Sun, 31 May 2020 22:10:16 +0200 (CEST) Date: Sun, 31 May 2020 22:10:16 +0200 From: Mark Wielaard To: Fangrui Song Cc: binutils@sourceware.org, gdb@sourceware.org, elfutils-devel@sourceware.org Subject: Re: Range lists, zero-length functions, linker gc Message-ID: <20200531201016.GJ44629@wildebeest.org> References: <20200531185506.mp2idyczc4thye4h@google.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20200531185506.mp2idyczc4thye4h@google.com> User-Agent: Mutt/1.10.1 (2018-07-13) X-Spam-Status: No, score=-4.9 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 20:10:49 -0000 Hi, On Sun, May 31, 2020 at 11:55:06AM -0700, Fangrui Song via Elfutils-devel wrote: > what linkers should do regarding relocations referencing dropped > functions (due to section group rules, --gc-sections, /DISCARD/, > etc) in .debug_* > > As an example: > > __attribute__((section(".text.x"))) void f1() { } > __attribute__((section(".text.x"))) void f2() { } > int main() { } > > Some .debug_* sections are relocated by R_X86_64_64 referencing > undefined symbols (the STT_SECTION symbols are collected): > > 0x00000043: DW_TAG_subprogram [2] > ###### relocated by .text.x + 10 > DW_AT_low_pc [DW_FORM_addr] (0x0000000000000010 ".text.x") > DW_AT_high_pc [DW_FORM_data4] (0x00000006) > DW_AT_frame_base [DW_FORM_exprloc] (DW_OP_reg6 RBP) > DW_AT_linkage_name [DW_FORM_strp] ( .debug_str[0x0000002c] = "_Z2f2v") > DW_AT_name [DW_FORM_strp] ( .debug_str[0x00000033] = "f2") > > > With ld --gc-sections: > > * DW_AT_low_pc [DW_FORM_addr] in .debug_info are resolved to 0 + > addend This can cause overlapping address ranges with normal text > sections. {{overlap}} * [beginning address offset, ending address > offset) in .debug_ranges are resolved to 1 (ignoring addend). See > bfd/reloc.c (behavior introduced in > https://sourceware.org/git/?p=binutils-gdb.git;a=commit;h=e4067dbb2a3368dbf908b39c5435c84d51abc9f3 > ) > > [0, 0) cannot be used because it terminates the list entry. > [-1, -1) cannot be used because -1 represents a base address > selection entry which will affect subsequent address offset > pairs. > * .debug_loc address offset pairs have similar problem to .debug_ranges > * In DWARF v5, the abnormal values can be in a separate section .debug_addr > > --- > > 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. Cheers, Mark