public inbox for gnu-gabi@sourceware.org
 help / color / mirror / Atom feed
From: Florian Weimer <fweimer@redhat.com>
To: Jozef Lawrynowicz <jozef.l@mittosystems.com>
Cc: James Y Knight via Gnu-gabi <gnu-gabi@sourceware.org>
Subject: Re: [RFC] Proposal for new ELF extension - "Symbol meta-information"
Date: Tue, 01 Sep 2020 14:48:04 +0200	[thread overview]
Message-ID: <873641u0hn.fsf@oldenburg2.str.redhat.com> (raw)
In-Reply-To: <20200901121922.srcmdfc4o4rd62go@jozef-acer-manjaro> (Jozef Lawrynowicz's message of "Tue, 1 Sep 2020 13:19:22 +0100")

* 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.

The main risk is processing objects with tools that don't know about the
symbol table relationship of this parallel tables.  To deal with that,
having a special section that lists the section types that absolutely
need to be understood by tools in order to process the object in various
ways (a distinction between reading, linking, and outputting might make
sense) could really be helpful.  You would get a precise error, rather
than a corrupt output file.

I'm not sure if it is possible to have meaningful symbol metadata that
can be processed by old tools in some meaningful way, tools that have no
prior knowledge of it.  It's very hard to design these things,
especially when we have only three established use cases.

Thanks,
Florian


  reply	other threads:[~2020-09-01 12:48 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 [this message]
2020-09-02 10:26           ` Jozef Lawrynowicz
2020-09-03 16:49             ` 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=873641u0hn.fsf@oldenburg2.str.redhat.com \
    --to=fweimer@redhat.com \
    --cc=gnu-gabi@sourceware.org \
    --cc=jozef.l@mittosystems.com \
    /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).