From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-pj1-f67.google.com (mail-pj1-f67.google.com [209.85.216.67]) by sourceware.org (Postfix) with ESMTPS id 63465384607B; Thu, 1 Oct 2020 19:22:13 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org 63465384607B Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=maskray.me Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=emacsray@gmail.com Received: by mail-pj1-f67.google.com with SMTP id b17so2439274pji.1; Thu, 01 Oct 2020 12:22:13 -0700 (PDT) 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:subject:message-id:references :mime-version:content-disposition:in-reply-to; bh=kvXgUM1DFJDT08qCTssJgHEt13rNMpDgTbJ6AICmO3A=; b=UM7DhOgxiAUn8OHBtHyionBoEmI1d2a7wTTRMvlTiy8g8jEIgDcwLZc3K1PdHBQqCF EgIIBhhpie8pTzrHxjJjh9plOWhxc9uoLxoMILV2a5WtlAKOCm7zzR/XA83kzm6v27PR AG1vG/BCJPtIs7zs2EmE+u8Ac1pYgeHNLb5h3tCkRpk6Y7JGZAv7XWFw5iBo6s005IjM FOGhfuBG/kVbVDacUVambywKIXmKooJlKOFv7MU7/aKSoq613l+qEND4leEt2nQy77gh a23LiK3VPRzmtzCxOjlkPB3ktwe5iHnTZrN9MCePjkv5xxx9JGjMkrixbGGhvDQuE/1J 0zwA== X-Gm-Message-State: AOAM531hwrIWrLfQ1nEdPi7Rk3rFYVVdyblsLEY08SgKFPX+AjTZP3MU /1z577gpXnHJeJFEaj96H9c= X-Google-Smtp-Source: ABdhPJznMhuM6Siisz6jco7AhSc5Yf+Zwc3PxtiWeQfvpviD735T9DLacMiYC+ugpyw9oi1pPMb01Q== X-Received: by 2002:a17:90a:648d:: with SMTP id h13mr1372618pjj.151.1601580132517; Thu, 01 Oct 2020 12:22:12 -0700 (PDT) Received: from localhost ([2601:647:4b01:ae80::51fb]) by smtp.gmail.com with ESMTPSA id k128sm8593723pfd.99.2020.10.01.12.22.11 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 01 Oct 2020 12:22:12 -0700 (PDT) Date: Thu, 1 Oct 2020 12:22:11 -0700 From: Fangrui Song To: 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: <20201001192211.samopetmxsdfwjnb@gmail.com> 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> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Disposition: inline In-Reply-To: <20200930101831.vi7pxhstftemanfc@jozef-acer-manjaro> X-Spam-Status: No, score=-3.0 required=5.0 tests=BAYES_00, FREEMAIL_FORGED_FROMDOMAIN, FREEMAIL_FROM, HEADER_FROM_DIFFERENT_DOMAINS, KAM_DMARC_STATUS, KAM_INFOUSMEBIZ, KAM_MANYTO, RCVD_IN_DNSWL_NONE, RCVD_IN_MSPIKE_H3, RCVD_IN_MSPIKE_WL, SPF_HELO_NONE, SPF_PASS, TXREP autolearn=no 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: Thu, 01 Oct 2020 19:22:23 -0000 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.