From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wm1-x343.google.com (mail-wm1-x343.google.com [IPv6:2a00:1450:4864:20::343]) by sourceware.org (Postfix) with ESMTPS id 741A83842413 for ; Fri, 2 Oct 2020 12:44:09 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org 741A83842413 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-x343.google.com with SMTP id q9so1552797wmj.2 for ; Fri, 02 Oct 2020 05:44:09 -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=k/7fD/67BJxblO9nEtFCIWMr2Pj5//DphyeP7ZgOVGs=; b=BMa72rVVb3X2PrE/GeXOQDwLWEFJDsnD6yWJ77pZFMCQlxI5rcGYjUB+DZdWzHiaeB cZQpWhju4S9H+bdrWQ/Co/GV0qm9gdELb8nzNIVJ7cqF9puqjbIYRdgbEzmnEgkeD8NO DAkYidCJhrKdBBBDvK3ELADnkftS5v5RmDKcrSjI5bXRe6XMmuSZ/QRd4+5+R21Wb/YG rVBq4DR3Kc3cSdV03mVCLx9aaakrzaQ5eVhYbqz8I5GLZhAoJiSWQiDSGn8ez6OuRJHL wUt/OPi3ORKMA6QjLttN/buUjjYKz4zhn6Q8VHG0RWIGiNaPXdnTNofqRVqED6aGccam h9PQ== 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=k/7fD/67BJxblO9nEtFCIWMr2Pj5//DphyeP7ZgOVGs=; b=DOjjhm/ViM6mvaV5QE+gXnPXwb+AjUwcQ7o7R+2g8ygs5FgGLbY7VM1Zd3tSQEbJYF s60hnYHIDlDPAix7oEZbKvnvDbrFGpQfCY+rCUgoI5UD4Akl2sR4tcFrQeITQoT6zSQ/ ZXASaKz8ggV4x877aLcZrUpQ0ozxxrIxvIxILk0EqWZPXAMt+aCMJx0R3Ruk/kHFzsAa MChSdDab4ylWAc1qI0b2KhWk+0vY31rbVWmcOdXp7D1DmLMIqzSjdEro05ptFUZ02SQQ 5xOGPE7BY7t415W9yJ7EWAYir3w5nQIOZ9dy6IWXY6pAwCAUtCZ83nXPRF+3Ioc/PaUE wT0w== X-Gm-Message-State: AOAM5328PomF+A7KKcH3LA2rO8veplc31/yev3SO1xit1L9mTQvctB7G 9IXHKgN/So+TwYAELihHUaEwEQ== X-Google-Smtp-Source: ABdhPJyrqQHKzym08zUs3XoLGZ+QuiO4wrLJprYW2JHOOM4G78a0qBwiyKiECfgLehGGiDkSjT5lNg== X-Received: by 2002:a1c:4e16:: with SMTP id g22mr2574522wmh.99.1601642648460; Fri, 02 Oct 2020 05:44:08 -0700 (PDT) Received: from jozef-acer-manjaro ([2a01:4b00:87fd:900:5e1d:5c99:56da:76e8]) by smtp.gmail.com with ESMTPSA id l3sm1768417wmh.27.2020.10.02.05.44.07 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 02 Oct 2020 05:44:07 -0700 (PDT) Date: Fri, 2 Oct 2020 13:44:06 +0100 From: Jozef Lawrynowicz To: Fangrui Song Cc: Roland McGrath , "H.J. Lu" , Binutils Development , gnu-gabi@sourceware.org, Peter Smith , George Rimar , James Henderson , James Y Knight Subject: Re: [PATCH v2] Support for SHF_GNU_RETAIN ELF Section Flag Message-ID: <20201002124406.jxofufi3rbdrr5nz@jozef-acer-manjaro> Mail-Followup-To: Fangrui Song , Roland McGrath , "H.J. Lu" , Binutils Development , gnu-gabi@sourceware.org, Peter Smith , George Rimar , James Henderson , James Y Knight References: <20200928132613.btkqaoomv4fdnupn@jozef-acer-manjaro> <20200929044353.vx26ypc2oioqbmfb@gmail.com> <20200929100442.o3e66jbmqpv5cajh@jozef-acer-manjaro> <20200929193806.m6u6ra6oijqkstfo@gmail.com> <20200929213741.jqegh62d7jne5uyo@jozef-acer-manjaro> <20200930101831.vi7pxhstftemanfc@jozef-acer-manjaro> <20201001192211.samopetmxsdfwjnb@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20201001192211.samopetmxsdfwjnb@gmail.com> X-Spam-Status: No, score=-4.8 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: gnu-gabi@sourceware.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Gnu-gabi mailing list List-Unsubscribe: , List-Archive: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Oct 2020 12:44:11 -0000 On Thu, Oct 01, 2020 at 12:22:11PM -0700, Fangrui Song wrote: > On 2020-09-30, Jozef Lawrynowicz wrote: > > On Tue, Sep 29, 2020 at 05:10:09PM -0700, Roland McGrath wrote: > > > Since group semantics mean that if any section in a group is retained the > > > whole group must be retained, it seems to me that making the feature a > > > group flag rather than a section flag makes sense. I don't think it really > > > has any downside. It's a little bit more structure to generate a group but > > > everything already knows how to do it so that should be no problem. While > > > it is true that multiple sections with the same name and different > > > attributes should already be fine, the place where multiple different > > > sections of the same name are usually seen today is when each different > > > section reusing a name is in a different group from the other sections with > > > the same name. > > > > > > > Let's assume: > > GRP_RETAIN > > Sections in a group with this flag set should always be included in > > the linked object, even if they appear unused. > > > > One issue I have with the group method is conceptual; groups are supposed > > to be used to group related sections. They are related because of their > > meaning from the application perspective, not because of their metadata > > (i.e. sections to be retained are related by their metadata because they > > all should be retained). > > > > Just because groups have a side effect that can be leveraged to > > get a section to be retained in the final link, why does that mean we > > need to leverage that property when it it's not actually the simplest or > > most obvious way to implement the new behavior? > > > > SHF_GNU_RETAIN describes in the simplest possible way that the section > > should be retained in the final link, without relying on other > > constructs. > > > > Just because groups are discarded or retained as a group, doesn't mean > > we need to leverage groups to try and implement retention or discarding > > functionality. > > > > Why wasn't SHF_EXCLUDE implemented as a group flag? After all, groups > > are included or excluded from the link together. > > GRP_EXCLUDE > > Sections in a group with GRP_EXCLUDE set should be discarded from > > the link. > > > > I mean, you could kind of use groups for anything when you decide > > grouping sections by metadata is OK. > > Why define SHT_NOBITS when you can create: > > GRP_NOBITS > > Sections in this group occupy no space in the file. They must have > > type SHT_PROGBITS. > > > > Retention of a section is a property of the section. We are misusing ELF > > constructs by using groups to indicate an arbitrary section needs to be > > retained. > > > > Another issue (if more is needed) is about how to name the groups. > > * If it is mandated that GRP_RETAIN groups have the same name e.g. > > "grp_retain", that means you can't put a section you want to > > retain in a different logical group that makes sense from the > > application perspective. So the other sections you would want to put > > in a group with the retained section need to all be put in a bundle > > with all the other GRP_RETAIN sections. > > * If GRP_RETAIN groups can have any name, so you can have multiple > > GRP_RETAIN groups, how does the compiler decide how to name the > > groups? It seems like it would be a mess. "grp_retain0", "grp_retain2" > > ... "grp_retain10" from one object file, "grp_retain0"... > > "grp_retain5" from another. Extra processing in the > > linker to clean up these group names and keep them unique would be > > required when performing a relocatable link. > > > > As a general point, what if I decide that there's enough pressure from > > the anti-SHF_GNU_RETAIN side that I change the implementation to use > > groups. But then those who already backed the flag prefer that method > > over using groups think the implementation should not have been changed. > > > > I feel like we already got enough backing for SHF_GNU_RETAIN between the > > GNU gABI and Binutils discussions. I understand, and welcome, more > > feedback, but I haven't been convinced any other method is obviously > > better than SHF_GNU_RETAIN, so why change it? > > > > I'm not saying it's possible to quantify which mechanism for "retain" is > > best, but SHF_GNU_RETAIN is the simplest, most obvious, and easiest to > > understand. Surely that gives it top marks? > > > > I'm also yet to hear one convincing reason why SHF_GNU_RETAIN is bad. > > As far as I can tell, the main argument against it stems from the fact > > that you can have two input sections with the same name but different > > SHF_GNU_RETAIN flag states. Not only is this a non-issue, groups have > > exactly the same problem! > > > > It would be great if a global maintainer to chime in on whether the > > attached patch is acceptable, because otherwise we are going to go back > > and forth forever. > > > > Thanks, > > Jozef > > Hi Jozef, > > I have checked with a few folks on the LLVM side. James Henderson and James Y > Knight seem to prefer a section flag to other mechanism. I prefer a > section flag, too (I was on the fence and wanted the alternatives to be considered). > > About the section flag 'R' in assembly: > > I'd still prefer an error to not add another exception to https://sourceware.org/pipermail/binutils/2020-February/109945.html > (a consensus GNU as and LLVM's integrated assembler have reached) > > .section retain,"a",@progbits > .section retain,"aR",@progbits # error for section flags change > > If a separate section is desired, I'd prefer an explicit ,unique,0 or ,unique,1 or ... > > .section retain,"a",@progbits > .section retain,"aR",@progbits,unique,0 # 'unique' is a binutils 2.35 feature (available in LLVM for a while) > > > About the use case in GCC (and probably Clang in the future): > > // a.h > __attribute__((section("sec"))) inline void bar() { ... } > > // a.c > #include "a.h" > __attribute__((section("sec"), retain)) // retain may be the pre-existing used. > void foo() { ... } > > Perhaps there needs a function attribute to lower to ,unique,1 in assembly. Hi Fangrui, My revised implementation for the "retain" attribute in GCC is for declarations with this attribute to always be placed in their own, uniquely named section. This will leverage the same mechanism that the -f{function,data}-sections options use. The "unique" option to the .section directive will not be required. I don't think there is any downside to doing this, compared to using the default section name, and it solves the issue of having two sections with the same name but different flags. I therefore no longer have any specific need for > .section retain,"a",@progbits > .section retain,"aR",@progbits # error for section flags change to be supported by GAS, and could remove that support from my next iteration of the Binutils patch. Thanks, Jozef