From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-il1-x143.google.com (mail-il1-x143.google.com [IPv6:2607:f8b0:4864:20::143]) by sourceware.org (Postfix) with ESMTPS id 1FD1D3943540; Wed, 30 Sep 2020 14:02:29 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org 1FD1D3943540 Received: by mail-il1-x143.google.com with SMTP id u9so1472564ilj.7; Wed, 30 Sep 2020 07:02:29 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to; bh=HHw93xFPKjQQXhK5r6ZR5hHKvTJVD3ESYysKBCJHkz8=; b=W8AJK467Wtj8Tc+3FUQlcZLA+AXm1/wsyuxL7Pv5tQtHHL1bA4S0UNDtJvpfT9JYwF Ugf47pkcR9qcgosfsDE5F8dksvkUPXyxgGq/Ip82j4jPQ5eNiYoYu+bwD+t+hfRcws5G 2MK84/u4YlRlrHdHrX2ozOox5iYCbcbHOy2hUaGAkVK3Gw/z1YF09QSm85ltRc/XUiYi FSrwyr2tFdjTEqWK3eRhopSduJdbI2NTxZphV+rOm3Mir3icNH/+ZHuQKQ+hVegt0LtJ saUu2kHriu8LQFm701X+FWVzMRnT+4e4e9Nletw0g9++DO1fPdISktmS+26dPJ1IWrla SZww== X-Gm-Message-State: AOAM533QPcIyd0kz3MplNPC+ib/YLrWNHNezlfSBt/fKsGpqUaII+tLA VIghRtzONl8N0lpQBUweMRuiRlNBqnJjfreRqCKeVlim9kQ= X-Google-Smtp-Source: ABdhPJxD68rl+68YZA+53A6vwbtn6Tx0Dl1liLTcrmGxx86Vl4d70EWVAOo4sscy4NWw8MHR6HIVnAIPiwidxAR2Ez4= X-Received: by 2002:a92:5205:: with SMTP id g5mr2193151ilb.273.1601474548510; Wed, 30 Sep 2020 07:02:28 -0700 (PDT) MIME-Version: 1.0 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> In-Reply-To: <20200930101831.vi7pxhstftemanfc@jozef-acer-manjaro> From: "H.J. Lu" Date: Wed, 30 Sep 2020 07:01:52 -0700 Message-ID: Subject: Re: [PATCH v2] Support for SHF_GNU_RETAIN ELF Section Flag To: Roland McGrath , Fangrui Song , Binutils Development , GNU gABI gnu-gabi Content-Type: text/plain; charset="UTF-8" X-Spam-Status: No, score=-3031.8 required=5.0 tests=BAYES_00, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, FREEMAIL_FROM, 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: Wed, 30 Sep 2020 14:02:30 -0000 On Wed, Sep 30, 2020 at 3:19 AM 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. > I like SHF_GNU_RETAIN which is complementary to SHF_EXCLUDE. -- H.J.