From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wr1-x444.google.com (mail-wr1-x444.google.com [IPv6:2a00:1450:4864:20::444]) by sourceware.org (Postfix) with ESMTPS id 7D50B3851C33 for ; Mon, 1 Jun 2020 16:25:29 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org 7D50B3851C33 Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=embecosm.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=andrew.burgess@embecosm.com Received: by mail-wr1-x444.google.com with SMTP id r7so473192wro.1 for ; Mon, 01 Jun 2020 09:25:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=embecosm.com; s=google; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to; bh=XS+Sv8mg2TZC+0hd2ZQrfCnvncs7vEwtwj/KpjpkHjw=; b=hMqrqFRGHbZ9DiUSolEE4WhWutYe6AhZX1UOBvLTebNN/590y++ST78Uq+tyZkaKWZ PAOprPFCEx5n8oDIj38Xx6cOeFH97p7Uaj6zsoSBaCUP47w7/bLs7CZnBWUMxBzxj2oW 66FuY6GexJFQShvY1gkE9Twyv/vGdgyFXQ7zWVHdw+BZygVy7Lk4VGEcijo1jaJ2m2R2 Cx5ciWd72OoURPTDqMM+ADnAHYig2SKhmf0D0dztRT/m58ZZSwe30z3JbTa6fYaOC5qU leJyiJIjEbY6hXdg/o/bwrUs2Aj1Rsm1IcMG+D45HwdE2XlH/62O8XiLRVHcoRG1GyW2 QbsA== 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=XS+Sv8mg2TZC+0hd2ZQrfCnvncs7vEwtwj/KpjpkHjw=; b=NgCa/u5y0WeW8BK498yYwv0O9q3iw7XLR6NZDPHxYYWCgbnA5E2uVkatoL+edEVbfs Pncoht77dJE5zUJkZKpgKbneFn7+VT6/eztJI6AG65Z13BJul/w1Uil2BxrtucxOZTV6 JVlrA9j4+QLXICezYnXmgje63D4VzS9pTo/aXfWfswmzRFWR1HvHz25eASV1WmLxQD2E MKxILMeP0WSmInjBi05GBnNTt1oSjGvaLojzEucOcrYUWo4ENWpExciC4GhJv6hPNCTH PQtnV4365REnKz0fctK+8jP+L4sOKDiC5TVZPW52ngWTCL39O30mbyjJBDeWu9WA3G2a hLTQ== X-Gm-Message-State: AOAM531RTdhe/P6QILMWM1H3rCjqLZHoudWkFiitKTZh9gyT4jbM0lo9 vezbS8tTDzD9jpMzUlJtnHkjxtNF3t8= X-Google-Smtp-Source: ABdhPJwTRxrEQHxoGPkpY5JKsgKIMO/ccGyFR2is7FJzTMo8ONpOOaWcWWbVtkgnvZ3yr9PdYlgY8A== X-Received: by 2002:adf:eacc:: with SMTP id o12mr4958789wrn.139.1591028728521; Mon, 01 Jun 2020 09:25:28 -0700 (PDT) Received: from localhost (host86-128-12-16.range86-128.btcentralplus.com. [86.128.12.16]) by smtp.gmail.com with ESMTPSA id 138sm137672wma.23.2020.06.01.09.25.27 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 01 Jun 2020 09:25:27 -0700 (PDT) Date: Mon, 1 Jun 2020 17:25:26 +0100 From: Andrew Burgess 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: <20200601162526.GI2242921@embecosm.com> 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> X-Operating-System: Linux/5.5.17-200.fc31.x86_64 (x86_64) X-Uptime: 17:22:56 up 42 days, 6:57, X-Editor: GNU Emacs [ http://www.gnu.org/software/emacs ] X-Spam-Status: No, score=-3.2 required=5.0 tests=BAYES_00, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, RCVD_IN_BARRACUDACENTRAL, RCVD_IN_DNSWL_NONE, 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: Mon, 01 Jun 2020 16:25:31 -0000 * Fangrui Song via Gdb [2020-05-31 11:55:06 -0700]: > It is being discussed on llvm-dev > (https://lists.llvm.org/pipermail/llvm-dev/2020-May/141885.html https://groups.google.com/forum/#!topic/llvm-dev/i0DFx6YSqDA) > 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 > > --- > > To save your time, I have a summary of the discussions. I am eager to know what you think > of the ideas from binutils/gdb/elfutils's perspective. > > * {{reserved_address}} Paul Robinson wants to propose that DWARF v6 reserves a special address. > All (undef + addend) in .debug_* are resolved to -1. > > We have to ignore the addend. With __attribute__((section(".text.x"))), > the address offset pair may be something like [.text.x + 16, .text.x + 24) > I have to resolve the whole (.text.x + 16) to the special value. > > (undef + addend) in pre-DWARF v5 .debug_loc and .debug_ranges are resolved to -2 > (0 and -1 cannot be used due to the reasons above). > > * Refined formula for a relocated value in a non-SHF_ALLOC section: > > if is_defined(sym) > return addr(sym) + addend > if relocated_section is .debug_ranges or .debug_loc > return -2 # addend is intentionally ignored > > // Every DWARF v5 section falls here > return -1 {{zero}} > > * {{zero}} Can we resolve (undef + addend) to 0? > > https://lists.llvm.org/pipermail/llvm-dev/2020-May/141967.html > > > while it might not be an issue for ELF, DWARF would want a standard that's fairly resilient to > > quirky/interesting use cases (admittedly - such platforms could equally want to make their > > executable code way up in the address space near max or max - 1, etc?). > > Question: is address 0 meaningful for code in some binary formats? There are targets where 0 is valid code address, so we should avoid attaching special meaning to this where possible. Thanks, Andrew