public inbox for gnu-gabi@sourceware.org
 help / color / mirror / Atom feed
From: Jozef Lawrynowicz <jozef.l@mittosystems.com>
To: Carlos O'Donell <carlos@redhat.com>, Florian Weimer <fweimer@redhat.com>
Cc: gnu-gabi@sourceware.org
Subject: Re: [RFC] SHF_GNU_RETAIN ELF Section Flag
Date: Wed, 16 Sep 2020 15:13:45 +0100	[thread overview]
Message-ID: <20200916141345.wxae5ytkyybbpcec@jozef-acer-manjaro> (raw)
In-Reply-To: <95e4fd3d-1486-b700-29b0-8b126b24d0ca@redhat.com> <875z8dn9xj.fsf@oldenburg2.str.redhat.com>

On Wed, Sep 16, 2020 at 08:58:41AM -0400, Carlos O'Donell wrote:
> On 9/15/20 12:52 PM, Jozef Lawrynowicz wrote:
> > 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.
> 
> GRP_KEEP - Group of sections to always keep. Never discarded if included
>            in the link.
> 
> The benefit is you can give them a logical group name e.g. "cpu_features"
> and have more than one of them for accounting/documentation purposes.
> 
> You can implement a "KEEP" source markup based on gas' .section directive?

This is an interesting idea, but my initial thoughts are that it adds
some complexity that I don't think is required. There is already a lot
of information that can be gleaned from the section header, and the
symbols within that section.
Presumably the developer would have named the ISR/memory mapped
register symbol sensibly.

It doesn't seem very standard to make use of ELF constructs for
documenting why something has been done a certain way. You would just
use the construct to make something happen and have the "why" documented
elsewhere.

On Wed, Sep 16, 2020 at 03:11:20PM +0200, Florian Weimer 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.

Well this is intended for use by application code rather than libraries.
So all the objects that are part of the specific application and
explicitly passed to the link editor are going to be loaded.

(Please forgive any technical misuse of "application" above, but I hope
it is clear what I mean ;))

If a developer wants to use it in a library they'll have to take
precautions that it behaves as expected, by considering the object file
that the SHF_GNU_RETAIN section would reside in.

Thanks,
Jozef

  parent reply	other threads:[~2020-09-16 14:13 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
2020-09-18 18:09                         ` Florian Weimer
2020-09-16 14:13                   ` Jozef Lawrynowicz [this message]
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=20200916141345.wxae5ytkyybbpcec@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).