From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wr1-x441.google.com (mail-wr1-x441.google.com [IPv6:2a00:1450:4864:20::441]) by sourceware.org (Postfix) with ESMTPS id 42E603857C52 for ; Thu, 24 Sep 2020 13:49:17 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org 42E603857C52 Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=mittosystems.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=jozef.l@mittosystems.com Received: by mail-wr1-x441.google.com with SMTP id k15so3877813wrn.10 for ; Thu, 24 Sep 2020 06:49:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mittosystems.com; s=google; h=date:from:to:cc:subject:message-id:mail-followup-to:references :mime-version:content-disposition:in-reply-to; bh=53R92brlKuYMfcdBb9EndBdT+9lHEod7LR5t2fqotOE=; b=LB0cEFbU/lBPQg12yqpF9Gp9PdSNjE5qssjpH/bPJQkOO4X7WX9NCkjunO3S/cZqtJ wTlvtKclqPInsHNIg96Nt/FGAMDzfwAMww6Q5rpzAs8sRrRo5ig5pttmEoh8nfz65PUr 2JLAGsJxdHMfxATMgXUVlGC4WQyfhZ/MBkFE8kYG0G+TEx/h9hIyk1sY/ZheNJgLQ98j /FZP/wCy4rCelKuuGMIqX2K74JPkBrxh1obfWWlx/+ugvxsTD1nT503Z7uDEv3hQaQqc JtQRPWyv4ABNJyadzPMSbjZSmNvPDA1glpeejFkp/dU14cnxZ6mNtIZ4f/ol2krwYwrA wIIw== 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 :mail-followup-to:references:mime-version:content-disposition :in-reply-to; bh=53R92brlKuYMfcdBb9EndBdT+9lHEod7LR5t2fqotOE=; b=UD9xONo9fD7QMmAhfzfekX9JrUKitnPCCBdWB8U7rU3L0loE6s1kRGOzFOqBLv3wTv dQYBiKpZscy5OSQtal9xRO/3G2Nfnc4twqNg+Q5iq1ZWlJeR+wSkJNlQDjz1w5FQnLz+ O4t+6hosBjdw9iUBHiqkPEmW/2aYjZ52R3P1WO4UP8f9ygYFYjQZ3e+3AJWAAJVO5q+S EFEtx3VOEBGTkBFLq1kFJ1xEnurSJ03UFWNgb9RWTG/0jssJhZWE9WGdgZsvZ7WyO4mc OfPStVWKPIlPU9kvOIPttOz5vPrsAKSS66+PgT3DnNelg1uP4wiqaEX1lSA/42KvQKFk wqxw== X-Gm-Message-State: AOAM532KuVoMttbozu34eMbvuAMauhoO55W3RCVsecjI0jkI1iWbZ6Lt MPHQezBppJHOujwY2TFIlFiDjg== X-Google-Smtp-Source: ABdhPJxLEt+XOMywWcJLhys+l4bnXh83ycvSIuL1byasno1CksXrtmYqHdEPNPKKl8lOKYQZrn+Scw== X-Received: by 2002:a5d:60c6:: with SMTP id x6mr5754375wrt.157.1600955356304; Thu, 24 Sep 2020 06:49:16 -0700 (PDT) Received: from jozef-acer-manjaro ([2a01:4b00:87fd:900:5e1d:5c99:56da:76e8]) by smtp.gmail.com with ESMTPSA id b84sm4083043wmd.0.2020.09.24.06.49.15 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 24 Sep 2020 06:49:15 -0700 (PDT) Date: Thu, 24 Sep 2020 14:49:14 +0100 From: Jozef Lawrynowicz To: "H.J. Lu" Cc: Michael Matz , Binutils Subject: Re: [PATCH] Support SHF_GNU_RETAIN ELF section flag Message-ID: <20200924134914.fmkyo4xqimjatf7u@jozef-acer-manjaro> Mail-Followup-To: "H.J. Lu" , Michael Matz , Binutils References: <20200923095818.npbwybrm63vb4ejm@jozef-acer-manjaro> <20200923165211.fr4rqzp5uqqmrufq@jozef-acer-manjaro> <20200923184735.4k2tji4yro452bep@jozef-acer-manjaro> <20200923200437.mnegrmwebjuzmfeu@jozef-acer-manjaro> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Spam-Status: No, score=-4.9 required=5.0 tests=BAYES_00, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, RCVD_IN_DNSWL_NONE, 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:49:18 -0000 On Thu, Sep 24, 2020 at 06:18:05AM -0700, H.J. Lu via Binutils wrote: > On Wed, Sep 23, 2020 at 1:17 PM H.J. Lu 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 > > See users/hjl/elf/master branch at: > > https://gitlab.com/x86-binutils/binutils-gdb/-/commits/users/hjl/elf/master > > I removed the .retain directive. Thanks, the formalization of section flag merging in the assembler is nice. My only comment is that I used the "STT_*" syntax in the .type directive instead of % because some targets didn't like the % syntax and emmited an error. I don't remember which, maybe it was mmix-elf, in which case we don't care :) When I re-test I'll see if the errors pop up again. I still need to add the GNU OSABI handling, but with that and your patches we are probably ready to apply after a final official sign-off. How would that work logistically, I apply my patch and you apply yours after? Or do we align off-master and apply as one patch? Thanks, Jozef > > > 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. > > > > -- > > H.J. > > > > -- > H.J.