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 EB3923860C3A for ; Tue, 15 Sep 2020 16:52:58 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org EB3923860C3A 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 z4so4100805wrr.4 for ; Tue, 15 Sep 2020 09:52:58 -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:references:mime-version :content-disposition:in-reply-to; bh=DA9TElAfVhMHuhIjg8DwfBjr4mXMrAdUXrMuyMcg7kI=; b=Hrg0HdRu9wKaGpgffapjONaUi8Um1bGZwoA5Pcftf7FYfmf1jkvmXKSpBUdxDgISsL lOe94kN1QpKinEwi6xUI3jcftVHSMrK2tOwyWoU9tsOALTwbD790jU8vVc6v448wRYZQ 07YNdiPjOlDTjuqKUovQscPqMDRZMLCE3mTZMXEGDQNLQkHnCxvInxlMtFjIKirqUQtU jQ2qJMr6zUBo925tO22PZybmTXXvYNY99gkZU4ZBP+G8ZWoEatGZaqKsywnVg+ugAnWu uCNYDGu2TGZ3DptdhXW9UC7sT1ljunqF7AE0XbAtyHejqSOiK9hELgTDuJdYWJHWu9R0 sjtg== 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:references :mime-version:content-disposition:in-reply-to; bh=DA9TElAfVhMHuhIjg8DwfBjr4mXMrAdUXrMuyMcg7kI=; b=btv5IBKxigsWNxPnCHzvg7dJHqykNABOGX6e/OKxPlP7G94lIXaiQsPwu/ENeReZIZ y8X0/oeKzOj/DuR31gNIebtwLyxHhSUu4hAHeLERNZgWDHnp2AHU4V3Hiafku31BTe6Z 92O54qWo5Jyi3mzsYTCq47y9PEaomzTW4hYYQsi7DvgWQljU0NEOJrvFbAQdeBgjlEUy FLIqPMeHtY4kkdseukqJr/xs+EOX8dBXXxCKgAYO9mIiflR3WASAsRJwgS8waZ3SL5t5 cztw9X//vVw7KMNmOI5SFlL4vktz+LMuat5vkpQ10ZeL4VNqLb9eV1nV+7g2CYUSE7de qNLw== X-Gm-Message-State: AOAM533xvK4HyZ/hrVAmRmopt/R7QAJrcgeTKSf0Jc+K8JWYHCUP+7LG fFC+NFvYcE8l+w6aCWqqBQPLyA== X-Google-Smtp-Source: ABdhPJy9E+1tjaZCjxsOJ3Tv0v3FlEvfWdIapNIOceSs1jLAE2V6arcvVdQO8WveoUOhDsX3ZlIBtg== X-Received: by 2002:a5d:4d51:: with SMTP id a17mr22333686wru.248.1600188778006; Tue, 15 Sep 2020 09:52:58 -0700 (PDT) Received: from jozef-acer-manjaro ([2a01:4b00:87fd:900:5e1d:5c99:56da:76e8]) by smtp.gmail.com with ESMTPSA id l16sm31321797wrb.70.2020.09.15.09.52.56 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 15 Sep 2020 09:52:57 -0700 (PDT) Date: Tue, 15 Sep 2020 17:52:55 +0100 From: Jozef Lawrynowicz To: Carlos O'Donell Cc: Florian Weimer , gnu-gabi@sourceware.org Subject: Re: [RFC] SHF_GNU_RETAIN ELF Section Flag Message-ID: <20200915165255.fm53szwcabht77ig@jozef-acer-manjaro> 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> <30f44461-67b1-2428-7b0d-9a49520524b3@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <30f44461-67b1-2428-7b0d-9a49520524b3@redhat.com> X-Spam-Status: No, score=-5.2 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: Tue, 15 Sep 2020 16:53:00 -0000 On Tue, Sep 15, 2020 at 10:11:30AM -0400, Carlos O'Donell wrote: > 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. I suppose the most compelling use cases for SHF_GNU_RETAIN are when the dependency cannot be expressed with references to ELF sections. You can't use SHF_GROUP because there is nothing to group the section with. Consider when it is in fact the hardware that depends on the SHF_GNU_RETAIN section: - Interrupt vector table - Bootloader code - Memory mapped registers These use cases perhaps make more sense when paired another flag I was going to propose, which enables the setting of a section's VMA from the source code. So a user could set the value of a memory mapped register directly from the source code, without any help from the linker script. I realize these use cases are focussed towards embedded microcontrollers, but there are many different processors, following different processor-specific ABIs which fall under this category. Maybe I should just work towards getting this functionality added for ARM, and then whatever other targets want to use it can just piggyback off that... Thanks, Jozef > > 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. >