From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wm1-x342.google.com (mail-wm1-x342.google.com [IPv6:2a00:1450:4864:20::342]) by sourceware.org (Postfix) with ESMTPS id 3BD933857C5A for ; Wed, 23 Sep 2020 20:04:41 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org 3BD933857C5A 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-wm1-x342.google.com with SMTP id e11so5271101wme.0 for ; Wed, 23 Sep 2020 13:04:41 -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=fMGAYv7ZGt57CgoOgGww/JCJcNoVCWsoZpFO1IGGAPk=; b=N5yj92bR98N2UaGhda1SAao3vDMMVnp9E7+JHizLin2tVo1Ufn0ZoWJURBpdGIzUEA R7CcRN92lYRIp1XVi6bABMy35nDHYn1pQPHYSsf19PdxyzvELs6PK8JfK9hR1dNqiLuV ntaa6tj38Rg7uaWz/J7ag1oGWIdTnG2MSAw9TtpJEoXzc0eFNSran7b7LDZCbSEvK0CU 6HajC2QB5B/57DwgJLu3lX4BUL+K0CUyI6TRPQa1duK+xfaNr0JvH0jV9a84x8orz6k6 rNDrtfr7SBEGeipy1PxLRF6JcTjbhRlDRgXptFJ3ZMDs871+moPvf9n5zajcSgbvSk63 1TWQ== 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=fMGAYv7ZGt57CgoOgGww/JCJcNoVCWsoZpFO1IGGAPk=; b=gnAQt+e9E5AHpFjlojOvfMJo2XP9Qp1wwHpWjXaIbWt7AOg5SsWRjFVHvFK60+k9Ji erbS6Nnt4PtypSxBRF/AQPzPPkPNj0zw8DMK6oyfj5sD83/GyCOSNJfEVD+NlWwLDghN 21/jx56JpvYmGZ4erZusDR9LKMjTsxkxc5AHthV7P3E3JbjxanEJyg8zwQbZLK7/lUYR uP17IeGMuoZL5MuQ9u7Wzi94rT08F3ysdk++FxnYlGwcocNKgKhn1bzAojUN78gBCgLw EdAhl3Y9hotfh3qkA1sUMeR3Q25FciuDrSh6T8c5Wcq5icDR3G3mPoet6X7cfrkkMj3e ZjNg== X-Gm-Message-State: AOAM5328r3vpVZKFvDzBs0DuMAB7vKkCE7TxVZVPJ/zTVaMNnRatwF3l 7zJPaBs7WZ6ZdBJeTo208uruRw== X-Google-Smtp-Source: ABdhPJzM8xu/sfPc/JhVlwp/PhcCnklYfXfSf4SnVFLezBSeMdW4q4NNgVvjAqdnPXwtJtjNm/RumQ== X-Received: by 2002:a7b:c76d:: with SMTP id x13mr1226801wmk.10.1600891480162; Wed, 23 Sep 2020 13:04:40 -0700 (PDT) Received: from jozef-acer-manjaro ([2a01:4b00:87fd:900:5e1d:5c99:56da:76e8]) by smtp.gmail.com with ESMTPSA id g131sm807131wmf.25.2020.09.23.13.04.39 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 23 Sep 2020 13:04:39 -0700 (PDT) Date: Wed, 23 Sep 2020 21:04:37 +0100 From: Jozef Lawrynowicz To: "H.J. Lu" Cc: Michael Matz , Binutils Subject: Re: [PATCH] Support SHF_GNU_RETAIN ELF section flag Message-ID: <20200923200437.mnegrmwebjuzmfeu@jozef-acer-manjaro> Mail-Followup-To: "H.J. Lu" , Michael Matz , Binutils References: <20200923010930.xtc4mgmxsoesohkn@gmail.com> <20200923095818.npbwybrm63vb4ejm@jozef-acer-manjaro> <20200923165211.fr4rqzp5uqqmrufq@jozef-acer-manjaro> <20200923184735.4k2tji4yro452bep@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=-5.0 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: Wed, 23 Sep 2020 20:04:42 -0000 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. Thanks, Jozef > > > However, it would certainly be a useful enhancement for the linker, and > > is something I would be interested in working on in the future, so I > > appreciate the offer. > > > > -- > H.J.