From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-pl1-x644.google.com (mail-pl1-x644.google.com [IPv6:2607:f8b0:4864:20::644]) by sourceware.org (Postfix) with ESMTPS id 8585A383E804 for ; Sun, 31 May 2020 20:47:43 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org 8585A383E804 Received: by mail-pl1-x644.google.com with SMTP id v24so1353975plo.6 for ; Sun, 31 May 2020 13:47:43 -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=RW0h5cy6w1dc7PSlsw1GS7Ml/+KkaMMQ0IazTmkUMx0=; b=UarJwQX+TDX/3r3165BhMWikSL634qL54GuxroDraoUuqrFrGfN8psTQ9Qe514wzAC FCKhDSt8GKkqmGGHjGTk090RDt2kn/qiJ34Vg7DVmfnZoyJoOopZszfLUKnDvZ/ytiid Evkjp8ApJS+GTeqoTSIgadlMRv42uwfE6zBqTpJ0NW+rjhGGKBXg0G7YxDOiebJD25hp /mvFaHg204VN4KaulhCx+Fg2VU7YyNY/u90WO30iRwfVz5xrGvnM0SJzo2hzVYAywD4z qqy5R66qDWBqKp9ZxbPtfszqMcrbbZ9g1ssvuhNtcmc/HUwOyJavbCqTiYerVwie3RZS JfQA== X-Gm-Message-State: AOAM530ZyNC1YJUvJsZaE2Ye8PLcLghZkZmN5MLxX2Rsm/ns0/rM2y0f Gpf0wy9mK9v0uPDtnkmcuoCVcQ== X-Google-Smtp-Source: ABdhPJwD3eB0LxcYHxM2dRgyAFXmd2/kk1kaLPBtEiFhIas5/ixeT+5xrvXwPvvlulxlZlJ8CP6caQ== X-Received: by 2002:a17:902:8210:: with SMTP id x16mr17324028pln.284.1590958061946; Sun, 31 May 2020 13:47:41 -0700 (PDT) Received: from google.com ([2620:15c:2ce:0:9efe:9f1:9267:2b27]) by smtp.gmail.com with ESMTPSA id j15sm5726525pjj.12.2020.05.31.13.47.41 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sun, 31 May 2020 13:47:41 -0700 (PDT) Date: Sun, 31 May 2020 13:47:38 -0700 From: Fangrui Song To: Mark Wielaard Cc: binutils@sourceware.org, gdb@sourceware.org, elfutils-devel@sourceware.org Subject: Re: Range lists, zero-length functions, linker gc Message-ID: <20200531204738.xhyuemuaygi5ihdd@google.com> References: <20200531185506.mp2idyczc4thye4h@google.com> <20200531201016.GJ44629@wildebeest.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Disposition: inline In-Reply-To: <20200531201016.GJ44629@wildebeest.org> X-Spam-Status: No, score=-18.9 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=unavailable 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:47:45 -0000 On 2020-05-31, Mark Wielaard wrote: >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. 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 (https://lists.llvm.org/pipermail/llvm-dev/2020-May/141926.html) (Cost: sizeof(Elf64_Shdr) = 64, Elf_Word for the entry in .group, plus a string in .strtab unless you use the string ".debug_info" (reusing the string requires https://sourceware.org/bugzilla/show_bug.cgi?id=25380)) According to Peter Smith in the thread https://groups.google.com/forum/#!msg/generic-abi/A-1rbP8hFCA/EDA7Sf3KBwAJ , Arm Compiler 5 splits up DWARF v3 debugging information and puts these sections into comdat groups: "This approach did produce significantly more debug information than gcc did. For small microcontroller projects this wasn't a problem. For larger feature phone problems we had to put a lot of work into keeping the linker's memory usage down as many of our customers at the time were using 32-bit Windows machines with a default maximum virtual memory of 2Gb." See Ben, Ali and others' comments in the thread. Fragmented .debug_* may not be practical.