From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mx2.suse.de (mx2.suse.de [195.135.220.15]) by sourceware.org (Postfix) with ESMTPS id E58B33954084 for ; Thu, 24 Sep 2020 13:28:00 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org E58B33954084 Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=suse.de Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=matz@suse.de X-Virus-Scanned: by amavisd-new at test-mx.suse.de Received: from relay2.suse.de (unknown [195.135.221.27]) by mx2.suse.de (Postfix) with ESMTP id 2E103B1AE; Thu, 24 Sep 2020 13:27:59 +0000 (UTC) Date: Thu, 24 Sep 2020 13:27:59 +0000 (UTC) From: Michael Matz To: Fangrui Song cc: jozef.l@mittosystems.com, Binutils , "H.J. Lu" , ccoutant@gmail.com Subject: Re: [PATCH] Support SHF_GNU_RETAIN ELF section flag In-Reply-To: <20200923232943.kasbrmqtpone4yi7@gmail.com> Message-ID: References: <20200923010930.xtc4mgmxsoesohkn@gmail.com> <20200923095818.npbwybrm63vb4ejm@jozef-acer-manjaro> <20200923165211.fr4rqzp5uqqmrufq@jozef-acer-manjaro> <20200923184735.4k2tji4yro452bep@jozef-acer-manjaro> <20200923200437.mnegrmwebjuzmfeu@jozef-acer-manjaro> <20200923232943.kasbrmqtpone4yi7@gmail.com> User-Agent: Alpine 2.20 (LSU 67 2015-01-07) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII X-Spam-Status: No, score=-3.1 required=5.0 tests=BAYES_00, KAM_DMARC_STATUS, RCVD_IN_MSPIKE_H3, RCVD_IN_MSPIKE_WL, SPF_HELO_NONE, SPF_PASS, TXREP 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: binutils@sourceware.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Binutils mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Sep 2020 13:28:02 -0000 Hello, On Wed, 23 Sep 2020, Fangrui Song wrote: > Since SHF_GNU_RETAIN is a new feature, and we already have facility for > making arbitrary sections alive with R_*_NONE, can you highlight the > selling point of a new flag? I wouldn't call this a facility. I call it a hack that accidentally works for this purpose. > Copying me previous reply here > > We already have a way to create an artificial reference: > > > > .reloc ., R_X86_64_NONE, target_symbol > > > > If we allow a relocation number for the second operand > > > > .reloc ., 0, target_symbol > > > > this will be generic. You can insert the directives in a GC root (e.g. > > _start or a symbol referenced by -u or maybe an .init_array) > > If you do not want to touch the section containing the -e (--entry) symbol, > you > can use: > > .section .init_array.1,"a",@init_array > .reloc ., R_X86_64_NONE, retained_section And what makes .init_array be retained? To which data item does the relocation apply, what if .init_array is empty? I think using this to force sections be retained is a terrible idea (I was split minds about calling this idea cute vs. terrible ;-) ). > For a new section flag, there are a bunch of things needing thoughts I think the answer to each of these things is obvious: > * assembler > > The .retain directive seems to be discouraged... For section flags: > > .section .foo,"a" > .section .foo,"aR" # is this a new section > .pushsection .foo,"aR" # is this a new section > > Does the compiler need to remember that a section has the flag? Why should it need to remember? (E.g. GCC does, but why would it matter?) The assembler merges the flags, no need to remember things. > * linker > - What does -r do on two sections of the same, one with the flag and the other > without? (as HJ mentioned) It merges the flag with logical or. > - Does the output section have the flag? Yes. > - Does the flag retain other sections in the same section group? Yes. Ciao, Michael. > > > On 2020-09-23, H.J. Lu via Binutils wrote: > > On Wed, Sep 23, 2020 at 1:04 PM Jozef Lawrynowicz > > wrote: > > > > > > On Wed, Sep 23, 2020 at 12:03:28PM -0700, H.J. Lu via Binutils wrote: > > > > On Wed, Sep 23, 2020 at 11:47 AM Jozef Lawrynowicz > > > > wrote: > > > > > > > > > > On Wed, Sep 23, 2020 at 10:13:37AM -0700, H.J. Lu via Binutils wrote: > > > > > > On Wed, Sep 23, 2020 at 9:52 AM Jozef Lawrynowicz > > > > > > wrote: > > > > > > > > > > > > > > On Wed, Sep 23, 2020 at 01:51:56PM +0000, Michael Matz wrote: > > > > > > > > Hello, > > > > > > > > > > > > > > > > On Wed, 23 Sep 2020, H.J. Lu via Binutils wrote: > > > > > > > > > > > > > > > > > > I think that: > > > > > > > > > > > > > > > > > > > > > .section .text,"ax" > > > > > > > > > > > ... > > > > > > > > > > > foo: > > > > > > > > > > > ... > > > > > > > > > > > .retain > > > > > > > > > > > retained_fn: > > > > > > > > > > > ... > > > > > > > > > > > > > > > > > > > > is some nice syntactic sugar compared to: > > > > > > > > > > > > > > > > > > > > > .section .text,"ax" > > > > > > > > > > > ... > > > > > > > > > > > foo: > > > > > > > > > > > ... > > > > > > > > > > > .section .text,"axR" > > > > > > > > > > > retained_fn: > > > > > > > > > > > ... > > > > > > > > > > > > > > > > > > > > It's also partly for convenience; we have other directives > > > which are > > > > > > > > > > synonyms or short-hand for each other. > > > > > > > > > > > > > > > > > > > > > > > > > > > > You don't need to keep the whole section when only one symbol > > > should > > > > > > > > > be kept. Please drop the .retain directive. GCC, as and ld > > > should do the > > > > > > > > > right thing with > > > > > > > > > > > > > > > > > > .section .text,"ax" > > > > > > > > > ... > > > > > > > > > foo: > > > > > > > > > ... > > > > > > > > > .section .text,"axR" > > > > > > > > > > > > > > > > > > retained_fn: > > > > > > > > > > > > > > > > > > where foo can be dropped and retained_fn will be kept. > > > > > > > > > > > > > > > > This is not what we discussed at the ABI list, the flag is per > > > section, so > > > > > > > > either the whole section is retained or not. What you describe > > > is > > > > > > > > something else that would work on a per symbol basis, which > > > would have to > > > > > > > > be specified in a different way and might or might not be a good > > > idea. > > > > > > > > But let's not conflate these two. > > > > > > > > > > > > > > Also, the linker cannot currently dissect a section and remove a > > > > > > > particular unused symbol anyway. Since garbage collection only > > > operates > > > > > > > on the section level, marking the section itself as "retained" > > > seems > > > > > > > most appropriate. > > > > > > > > > > > > It can be done. If you put your branch on > > > > > > > > > > > > https://gitlab.com/x86-binutils/binutils-gdb > > > > > > > > > > > > I can help you implement it. > > > > > > > > > > It's not something I have time to look into at the moment, for now the > > > > > aim is just to prevent garbage collection of sections. > > > > > > > > Linker and assembler already support it. You just need to add > > > SHF_GNU_RETAIN > > > > to the framework. Check how SHF_GNU_MBIND works. > > > > > > Sorry, I don't understand. > > > > > > Are you saying that LD already supports the garbage collection of > > > individual unused symbol definitions from input sections? Whilst > > > retaining other symbol definitions which are required by the program? > > > I cannot find any reference to this. > > > > > > How does that relate to SHF_GNU_MBIND? I looked at all the references > > > to "mbind" in Binutils and nothing seemed related garbage collection of > > > sections, since SHF_GNU_MBIND is just used to indicate a particular > > > section should be placed in a special memory area. > > > > For > > > > section .text,"ax" > > ... > > foo: > > ... > > .section .text,"axR" > > retained_fn: > > > > you need to create a new .text section with SHF_GNU_RETAIN for > > retained_fn. See get_section in obj-elf.c. If you want to avoid > > merging .text section with SHF_GNU_RETAIN with other .text > > sections by ld -r, linker needs to distinguish sections of the > > same name with and without SHF_GNU_RETAIN. >