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 141DE3857C45 for ; Wed, 23 Sep 2020 18:47:38 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org 141DE3857C45 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 o5so1074132wrn.13 for ; Wed, 23 Sep 2020 11:47:38 -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=mg2IYaQ42eLrLjv+XJcUQymj6Mt6X8iLVfgW0v3rBIM=; b=ANZciS+RKGtI9ZaRkpNGaW/jBgp362duv8twIrKNSNsGBUm/t67V5MpFgt0O+qJchS O/8Rf68SJHpnWVxQF/1tiPoIiGW60ckGphISiUFpo9okxUwUAY3nyKDqfu5SEMxrCmzj tfYmUnnmAV+m8hnhyxiMCtpGgt7JMpFfU6QXuxPgkpIl4zz0WmDzsETq0bVV6+0SeKWH /c+ixeBW+RhVoveaWzvlJ/TBnd7MZ/7ijJWzPI+HvXbhenYQWiuHwP6cYlTosMxtSmyY WNj7uXlXfuPLfgKIbPtM9gLHHeGXXpKI4YRCwsWiWk4YLKB9kStUgLfuEQdN+s6sYO3y fFcQ== 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=mg2IYaQ42eLrLjv+XJcUQymj6Mt6X8iLVfgW0v3rBIM=; b=LU4LhX3Z72Yuonq01XFhitKjgTD06C+R42RGhSWyx+SSAOwQdCoI9b9VF2haot83tQ kx1cbRB+R/oHq5dbEpBKe1aA+Dn+765NdnIb8HTQEfsvGlo26ZRy6Nyrazzzuy1qJ8NW 9BDG3ZH4Nv4Lx53fm7sHp5T25pOYZr8WRze6F5Z3DnJd9eJyosIgiAsLlfLBduGKztvN JM3luA8aesFZ6NJAzXUOS5WhMaStltIQ6XH0IldpTq/zMpo5jlC5too9Qu0+6K5jTExR 2hWQcAvmpumhDgj8d7+XqCQ6jMA6RCcZWFppKrW/g+p2OeWbsLe8pWHuWGl+qRnJLgGH jqZA== X-Gm-Message-State: AOAM533IWnu8W0Hcu7V75zHsuoxbDKuvlwdhkPdLmcD7zpUXT2kwDA45 uuEnJggvxEfa9msUXogAN4qyY5i3VrKGXQ== X-Google-Smtp-Source: ABdhPJwZhjyeiLkaniJzDVILTAffS14FkPiRT7+gMVHd8W4AX7Af/bJKipAJdlW+8UhrVXU+V07M/Q== X-Received: by 2002:adf:e7ce:: with SMTP id e14mr1029822wrn.43.1600886857077; Wed, 23 Sep 2020 11:47:37 -0700 (PDT) Received: from jozef-acer-manjaro ([2a01:4b00:87fd:900:5e1d:5c99:56da:76e8]) by smtp.gmail.com with ESMTPSA id n14sm618227wmi.33.2020.09.23.11.47.36 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 23 Sep 2020 11:47:36 -0700 (PDT) Date: Wed, 23 Sep 2020 19:47:35 +0100 From: Jozef Lawrynowicz To: "H.J. Lu" Cc: Michael Matz , Binutils Subject: Re: [PATCH] Support SHF_GNU_RETAIN ELF section flag Message-ID: <20200923184735.4k2tji4yro452bep@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> 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 18:47:39 -0000 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. 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. Thanks, Jozef > > > As an aside.. we would run into limitations in the ELF format if trying > > to mark the symbol itself as "retained". You cannot define "retain" as a > > new symbol type or binding, because there is not a one-to-one mapping of > > "retain" to the existing symbol types and bindings i.e. a retained > > symbol might be STT_OBJECT or STT_FUNC, or STB_LOCAL or STB_GLOBAL. > > st_other could be another place to store the requirement to "retain" a > > symbol, but all those available bits are used up (albeit some > > unofficially). > > > > I'm not saying there's no way it could be done, but these are the > > hurdles I discovered when considering that path to implementing the > > "retain" behavior. > > > > > About the .retain syntactic sugar: I also think it's not necessary, the > > > .section directive with R flag merging is good enough IMHO. > > > > I'm OK with removing the .retain directive, since there is some > > consensus it is not necessary. Also, I thought it made life easier for > > GCC to mark sections as retained by omitting the section name from the > > directive, but I've discovered a way around that now. > > > > Thanks, > > Jozef > > > > -- > H.J.