public inbox for gnu-gabi@sourceware.org
 help / color / mirror / Atom feed
From: Jozef Lawrynowicz <jozef.l@mittosystems.com>
To: Florian Weimer <fweimer@redhat.com>
Cc: Carlos O'Donell <carlos@redhat.com>, gnu-gabi@sourceware.org
Subject: Re: [RFC] SHF_GNU_RETAIN ELF Section Flag
Date: Tue, 15 Sep 2020 14:29:55 +0100	[thread overview]
Message-ID: <20200915132955.gmklbme6h5x5izha@jozef-acer-manjaro> (raw)
In-Reply-To: <87mu1ri4ie.fsf@oldenburg2.str.redhat.com>

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.

Thanks,
Jozef

  reply	other threads:[~2020-09-15 13:30 UTC|newest]

Thread overview: 20+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-09-15 12:06 Jozef Lawrynowicz
2020-09-15 12:09 ` Florian Weimer
2020-09-15 12:31   ` Jozef Lawrynowicz
2020-09-15 12:37     ` Florian Weimer
2020-09-15 12:50       ` Carlos O'Donell
2020-09-15 12:55         ` Florian Weimer
2020-09-15 13:29           ` Jozef Lawrynowicz [this message]
2020-09-15 14:11             ` Carlos O'Donell
2020-09-15 16:52               ` Jozef Lawrynowicz
2020-09-16 12:58                 ` Carlos O'Donell
2020-09-16 13:11                 ` Florian Weimer
2020-09-16 13:46                   ` Michael Matz
2020-09-18 12:07                     ` Florian Weimer
2020-09-18 12:22                       ` Jozef Lawrynowicz
2020-09-18 18:09                         ` Florian Weimer
2020-09-16 14:13                   ` Jozef Lawrynowicz
2020-09-18 10:00                     ` Jozef Lawrynowicz
2020-09-18 18:11                       ` Florian Weimer
2020-09-21 12:42                         ` Michael Matz
2020-09-21 18:53                           ` Jozef Lawrynowicz

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20200915132955.gmklbme6h5x5izha@jozef-acer-manjaro \
    --to=jozef.l@mittosystems.com \
    --cc=carlos@redhat.com \
    --cc=fweimer@redhat.com \
    --cc=gnu-gabi@sourceware.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).