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: gnu-gabi@sourceware.org
Subject: Re: [RFC] Proposal for new ELF extension - "Symbol meta-information"
Date: Thu, 3 Sep 2020 17:49:32 +0100	[thread overview]
Message-ID: <20200903164932.g5yfpg6zepaxq2mu@jozef-acer-manjaro> (raw)
In-Reply-To: <20200902102623.w7gj7zxhkitonzfi@jozef-acer-manjaro>

On Wed, Sep 02, 2020 at 11:26:23AM +0100, Jozef Lawrynowicz wrote:
> On Tue, Sep 01, 2020 at 02:48:04PM +0200, Florian Weimer wrote:
> > * Jozef Lawrynowicz:
> > 
> > > I can imagine how the behavior could be implemented without any special
> > > handling from the linker, if the compiler instead maps the printf calls to the
> > > minimum required printf implementation, and the library has something
> > > like this:
> > 
> > Yes, exactly my thought.  It's definitely less action at a distance.
> > 
> > > Do you have any opinions on the inclusion of the symbol meta-information
> > > mechanism itself within the GNU gABI?
> > 
> > In the past, we just added a parallel table to the symbol table when we
> > needed to extend it.  I think SHT_GNU_versym is the most widely used
> > example.  This has the advantage that it is so much simpler.
> 
> It seems that the benefits of having a parallel symbol table outweigh
> any concerns about wasted space and the large amount of symbol metainfo
> entries which would not have any content.
> Since entry size is fixed, if you stored the header information in the
> initial NULL entry then there is the additional benefit that you could
> theoretically keep .symtab_meta in sync with .symtab by
> adding/removing symbols at a given index as required.

Do you think the symbol meta-information functionality implemented as a
parallel symbol table, and supporting the SMT_RETAIN and SMT_LOCATION
types, would be accepted as a GNU gABI extension?

Or should we pursue the other previously discussed approach of getting
"retain" and "location" attribute support into the GNU toolchain?

I think there are advantages and disadvantages to both methods, but the
impression I get is that the approach which requires the least drastic
changes to the ABI is preferable, which leads me to believe we should
look to implement the types using new ELF section flags instead.

Thanks,
Jozef

      reply	other threads:[~2020-09-03 16:49 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-08-31 11:58 Jozef Lawrynowicz
2020-08-31 12:23 ` Florian Weimer
2020-08-31 13:14   ` Jozef Lawrynowicz
2020-08-31 13:45   ` James Y Knight
2020-09-01 11:20     ` Florian Weimer
2020-09-01 12:19       ` Jozef Lawrynowicz
2020-09-01 12:48         ` Florian Weimer
2020-09-02 10:26           ` Jozef Lawrynowicz
2020-09-03 16:49             ` Jozef Lawrynowicz [this message]

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=20200903164932.g5yfpg6zepaxq2mu@jozef-acer-manjaro \
    --to=jozef.l@mittosystems.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).