From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [216.205.24.124]) by sourceware.org (Postfix) with ESMTP id C74263857820 for ; Tue, 15 Sep 2020 14:11:36 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org C74263857820 Received: from mail-qk1-f197.google.com (mail-qk1-f197.google.com [209.85.222.197]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-455-0AgtZdI-OAaR0KQ0Awy8aQ-1; Tue, 15 Sep 2020 10:11:34 -0400 X-MC-Unique: 0AgtZdI-OAaR0KQ0Awy8aQ-1 Received: by mail-qk1-f197.google.com with SMTP id h191so2979550qke.1 for ; Tue, 15 Sep 2020 07:11:34 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:organization :message-id:date:user-agent:mime-version:in-reply-to :content-language:content-transfer-encoding; bh=WVS+R/swMFDw5GSvJhhjPBOb4m66ENEkt+1LZ/xxeRQ=; b=Sn5AEARWKQ0qyDCPDslNDfg3q8lM3Z+Pq3ARS3pzNk5B2sHxEg3xrBjto20pcnup/6 ha2sFyzcfoZjlf7epRjuVRZ8ssMnnbaAimCduVmSwSfJ9fQs8SzjLOAlXAk2skarfhIv SF5PAxRBLmDkL8YcB8o1Ueq29z5JJUAOWKJqFcfSij4Z5FxPWPCItwlQTbqubrS3eyQ/ hPMiQcNGa1g/KObdi/BACsfOS50a7YE7FHDu95ZFbpINhHKgbGIGXTZMsmbSU99HLmdi OwN3TVUS5uPyCjVJlOrRCoPomVNN36vc+f04oXXnEBCBmuJmTGJEpEo6Mb+k07N/IY9+ F8EA== X-Gm-Message-State: AOAM531ixwwPPwMInia3D0XapKVCpxrqXx0jNhVmOoK5RNHI4jEbGGaY sPyxpC1NEVmlnzDaUCxrvWEzHhc5RmV1cj7DgTnoVcv6e4gPi0dsHUKCP1if+kwM9OM4PNP7ug2 nnmOVvz7yw2Jt893hDw== X-Received: by 2002:a0c:f0d1:: with SMTP id d17mr1980183qvl.34.1600179093488; Tue, 15 Sep 2020 07:11:33 -0700 (PDT) X-Google-Smtp-Source: ABdhPJxTfYiZm9LaL6CUCGP/xcRZNtTbN7okXhS1kRH1xcIofpWS84Fb9TWVmbWDAASxXpPcABm1BQ== X-Received: by 2002:a0c:f0d1:: with SMTP id d17mr1980153qvl.34.1600179093113; Tue, 15 Sep 2020 07:11:33 -0700 (PDT) Received: from [192.168.1.16] (198-84-214-74.cpe.teksavvy.com. [198.84.214.74]) by smtp.gmail.com with ESMTPSA id 76sm17012798qkl.127.2020.09.15.07.11.31 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 15 Sep 2020 07:11:32 -0700 (PDT) Subject: Re: [RFC] SHF_GNU_RETAIN ELF Section Flag To: Jozef Lawrynowicz , Florian Weimer Cc: gnu-gabi@sourceware.org References: <20200915120632.bs36vkrbvmsoyvnu@jozef-acer-manjaro> <877dsvjl71.fsf@oldenburg2.str.redhat.com> <20200915123155.xpow3oxpzycsq3ie@jozef-acer-manjaro> <87v9gfi5cf.fsf@oldenburg2.str.redhat.com> <87mu1ri4ie.fsf@oldenburg2.str.redhat.com> <20200915132955.gmklbme6h5x5izha@jozef-acer-manjaro> From: Carlos O'Donell Organization: Red Hat Message-ID: <30f44461-67b1-2428-7b0d-9a49520524b3@redhat.com> Date: Tue, 15 Sep 2020 10:11:30 -0400 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.11.0 MIME-Version: 1.0 In-Reply-To: <20200915132955.gmklbme6h5x5izha@jozef-acer-manjaro> X-Mimecast-Spam-Score: 0.001 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Content-Language: en-US X-Spam-Status: No, score=-7.6 required=5.0 tests=BAYES_00, DKIMWL_WL_HIGH, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, NICE_REPLY_A, RCVD_IN_DNSWL_NONE, RCVD_IN_MSPIKE_H5, RCVD_IN_MSPIKE_WL, 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: Tue, 15 Sep 2020 14:11:38 -0000 On 9/15/20 9:29 AM, Jozef Lawrynowicz wrote: > On Tue, Sep 15, 2020 at 02:55:05PM +0200, Florian Weimer wrote: >> * Carlos O'Donell: >> >>> On 9/15/20 8:37 AM, Florian Weimer via Gnu-gabi wrote: >>>> * Jozef Lawrynowicz: >>>> >>>>> On Tue, Sep 15, 2020 at 02:09:22PM +0200, Florian Weimer wrote: >>>>>> * Jozef Lawrynowicz: >>>>>> >>>>>>> I'd like to propose a new ELF section flag, SHF_GNU_RETAIN, for addition >>>>>>> to the GNU gABI. >>>>>>> >>>>>>> This flag instructs the linker to "retain" the section in the output >>>>>>> file, even if garbage collection would remove it because it appears >>>>>>> unused. >>>>>> >>>>>> How does this flag interaction with libraries (.a files)? >>>>> >>>>> If a section in a library has SHF_GNU_RETAIN set, and that library gets >>>>> searched by the linker for some undefined symbol, then the >>>>> SHF_GNU_RETAIN section will also be pulled into the program, and >>>>> retained in the linked output file. >>>> >>>> Sorry, that's not quite what I meant. What happens if the .o file with >>>> SHF_GNU_RETAIN in an .a library is not otherwise referenced and thus >>>> never loaded by the link editor? How would the link editor realize that >>>> it is even there? >>> >>> Why would it be loaded? >> >> Hypothetically: Because the ranlib section tells the link editor to load >> it (so more specification updates are needed). >> > > An SHF_GNU_RETAIN section would only be kept if it's containing object > was loaded in the first place, and the section was therefore considered for > garbage collection. So no, SHF_GNU_RETAIN is not intended to be used to > force inclusion of sections which the linker would not have otherwise > seen. > SHF_GNU_RETAIN can be thought of to essentially "turn off" garbage > collection for that section, rather than change the fundamental linking > behavior for that section or containing object. > > Carlos' ammendment to the definition is accurate: > >> SHF_GNU_RETAIN >> When an object file containing such a marked section is included in >> the link, the section should not be garbage collected by the linker, >> even if it appears unused. > >>> Why does the link editor need to detect the presence of such a file? >> >> To make SHF_GNU_RETAIN work with libraries. >> >> I think without that, the same effect can be had today with >> SHF_GROUP/SHT_GROUP, perhaps with an assembler-only change to implement >> the .retain pseudo. >> > > Perhaps, but without making any further extensions, wouldn't the > assembler need to know of a section which will definitiley be kept in > the output file? Only the linker can truly know this, by looking at the > entry point (when there is one). > > A new bit in GRP_MASKOS could define that sections in a group with this > flag must always be kept, but that seems like a more round about way of > using a new section flag. Florian's point here, and let me reiterate it to see if I understood it, is that SHF_GROUP / SHT_GROUP is the right mechanic here because: (a) *Something* needs the section that would otherwise have been garbage collected. (b) Expressing the "depends on" relationship could be achieved with a SHF_GROUP / SHT_GROUP and a new bit GRP_DEPENDS to indicate that a group of sections depend upon eachother (k-connected dependency). Then the linker during garbage collection must either be able to discard all sections in the group or none of them. The underlying idea here is that SHF_GNU_RETAIN is really an expression of "depended upon by something" with no further information about the dependee or other related dependents. How would "depends on" (GRP_DEPENDS) be expressed to the developer? They would have to put code, and data, and other things into the this new group to make a collection of things that depend upon eachother in some non-"symbol dependency" way. In the end you have to define the collection of things that would go into the section group. -- Cheers, Carlos.