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: Michael Matz <matz@suse.de>, gnu-gabi@sourceware.org
Subject: Re: [RFC] SHF_GNU_RETAIN ELF Section Flag
Date: Fri, 18 Sep 2020 13:22:55 +0100	[thread overview]
Message-ID: <20200918122255.oqgufi3jkc72sgem@jozef-acer-manjaro> (raw)
In-Reply-To: <87y2l770fl.fsf@oldenburg2.str.redhat.com>

On Fri, Sep 18, 2020 at 02:07:42PM +0200, Florian Weimer wrote:
> * Michael Matz:
> 
> > Hello,
> >
> > On Wed, 16 Sep 2020, Florian Weimer via Gnu-gabi wrote:
> >
> >> * Jozef Lawrynowicz:
> >> 
> >> > 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.
> >> 
> >> But if there is nothing to group the section with, why would the link
> >> editor load the object?
> >> 
> >> That's the part I don't understand.
> >
> > Hmm?  By putting it on the command line:
> >
> > % ld --gc-sections needed.o
> >
> > should retain the RETAIN sections from needed.o, even if otherwise not 
> > seemingly referenced.
> 
> But this use case already works today with an implicit linker script, I
> think:
> 
> $ cat needed-impl.S
> 	.section .data.need-to-be-kept
> symbol_to_be_retained:
> 	.long 0
> $ cat needed.o
> /* GNU ld script */
> INPUT (needed-impl.o)
> SECTIONS {
>   .data : {
>     KEEP (*(.data.need-to-be-kept))
>   }
> }
> $ gcc -c needed-impl.S
> $ gcc -shared -Wl,--gc-sections needed.o
> $ $ readelf -s a.out | grep symbol_to_be_retained
>     35: 0000000000004020     0 NOTYPE  LOCAL  DEFAULT   20 symbol_to_be_retained
> 
> (Some polishing by a linker expert is certainly needed, but I hope you
> get the idea.)

Yes, the use of the KEEP linker script directive is the current way to
protect a section from garbage collection, but in my original proposal
I outlined the benefits of using an attribute to save a section from
garbage collection. For the attribute to work, you need a section flag
to propagate the information to the linker.

On Tue, Sep 15, 2020 at 01:06:32PM +0100, Jozef Lawrynowicz wrote:

> ----------
> Motivation
> ----------
>
> ...snip...
>
> Currently, the KEEP linker script directive can be used to save a
> section from garbage collection. The new SHF_GNU_RETAIN flag has the
> same effect as KEEP, but since it is an ELF section flag, it means that
> this property can be propagated through the toolchain, from the
> compiler, through the assembler, to the linker.
>
> This enables a new "retain" attribute to be set on function and data
> declarations in the source code, which communicates the need to set the
> SHF_GNU_RETAIN flag on the containing section to downstream tools. In
> some situations, this has benefits over applying the KEEP directive in
> the linker script:
>
> - The requirement for protection from garbage collection might be
>   application-specific, so consolidating this requirement to be
>   contained entirely within the source code improves portability.
> - The user doesn't have to work out which section a function or data
>   object declaration will be placed in, and then set the KEEP directive
>   on that section. They can just set the attribute in the source code
>   and leave the rest for the toolchain to handle.
> - Generally avoiding linker script modifications can improve the user
>   experience, especially when the user is inexperienced with the linker
>   script format.  The boilerplate linker script code required for
>   standard application operation can make modifications error-prone and
>   have unintended side-effects.

So this new flag is not implementing a feature which is not currently
possible to do in any other way, but it opens up new ways to modify the
behavior of linker garbage collection, which can be used by developers
and writers of libraries/SDKs.

Thanks,
Jozef

  reply	other threads:[~2020-09-18 12:23 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
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 [this message]
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=20200918122255.oqgufi3jkc72sgem@jozef-acer-manjaro \
    --to=jozef.l@mittosystems.com \
    --cc=fweimer@redhat.com \
    --cc=gnu-gabi@sourceware.org \
    --cc=matz@suse.de \
    /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).