public inbox for binutils@sourceware.org
 help / color / mirror / Atom feed
From: Jozef Lawrynowicz <jozef.l@mittosystems.com>
To: "H.J. Lu" <hjl.tools@gmail.com>
Cc: "binutils@sourceware.org" <binutils@sourceware.org>
Subject: Re: [RFC] Symbol meta-information ELF extension
Date: Tue, 18 Feb 2020 18:55:00 -0000	[thread overview]
Message-ID: <20200218185454.056abc91@jozef-kubuntu> (raw)
In-Reply-To: <CAMe9rOp8HDf+Os9aiwZBOMMPjJjRWAaYG=mQ0Gz76QxwoAu1Gg@mail.gmail.com>

On Tue, 18 Feb 2020 06:50:58 -0800
"H.J. Lu" <hjl.tools@gmail.com> wrote:

> On Tue, Feb 18, 2020 at 6:38 AM Jozef Lawrynowicz
> <jozef.l@mittosystems.com> wrote:
> >
> > On Tue, 18 Feb 2020 05:58:34 -0800
> > "H.J. Lu" <hjl.tools@gmail.com> wrote:
> >  
> > > On Tue, Feb 18, 2020 at 5:47 AM Jozef Lawrynowicz
> > > <jozef.l@mittosystems.com> wrote:  
> > > >
> > > > On Tue, 18 Feb 2020 04:58:02 -0800
> > > > "H.J. Lu" <hjl.tools@gmail.com> wrote:
> > > >  
> > > > > On Tue, Feb 18, 2020 at 2:26 AM Jozef Lawrynowicz
> > > > > <jozef.l@mittosystems.com> wrote:  
> > > > > >
> > > > > > Hi,
> > > > > >
> > > > > > I've been working with Texas Instruments to develop an ELF extension which
> > > > > > allows additional information about symbols ("symbol meta-information") to
> > > > > > be stored in ELF files, in a section called .symtab_meta.
> > > > > >
> > > > > > The aim of symbol meta-information is to provide a extensible format for
> > > > > > propagating additional information about symbols from the source code through to
> > > > > > the link stage.
> > > > > >
> > > > > > I hope I can get some feedback on this proposal, and its current implementation,
> > > > > > from the upstream community so I can make any adjustments required for the
> > > > > > eventual upstreaming of this feature.  
> > > > >
> > > > > Have you looked at Solaris syminfo section
> > > > >
> > > > > https://docs.oracle.com/cd/E26502_01/html/E26507/chapter7-17.html
> > > > >
> > > > > Can you extend it to do what you want?
> > > > >  
> > > >
> > > > It looks like there is only some minimal support for the Syminfo section in
> > > > Binutils. The support is only there so that readelf can dump information about
> > > > the Syminfo section from an object file.
> > > >
> > > > There's no implementation to enable the creation of a Syminfo section with
> > > > user-specified flags for certain symbols, nor are there any hooks into any
> > > > other Binutils programs, so I can't see any advantage to try and leverage that
> > > > existing functionality.  
> > >
> > > syminfo is a very useful ELF extension.  My question is if binutils supports
> > > syminfo, can it be extended to meet your need?
> > >
> > >  
> >
> > Well, a syminfo entry has a field to store flags which describes the extra
> > information about the symbol, similar to the "kind" field of a symbol
> > meta-information entry.
> >
> > typedef struct {
> >         Elf64_Half      si_boundto;
> >         Elf64_Half      si_flags;
> > } Elf64_Syminfo;
> >
> > Meanwhile, syminfo augments the si_flags value by using si_boundto to point
> > to an index in the .dynamic section. This is similar to how the "value" field of
> > a symbol meta-information entry augments its "kind" field, but this
> > functionality must work in static executables which do not have a .dynamic
> > section.
> >
> > So one way to extend syminfo to meet the general need of this proposed symbol
> > meta-information functionality then we would need a new field to store the
> > value associated with the "si_flags".
> >
> > typedef struct {
> >         Elf64_Half      si_boundto;
> >         Elf64_Half      si_flags;
> >         Elf64_Addr      si_value;
> > } Elf64_Syminfo_new;  
> 
> You should start a discussion to extend ELF symbol info at
> 
> https://groups.google.com/forum/#!forum/generic-abi

Thanks for the suggestion. I'll work with TI to get something posted there soon.

Can you clarify whether you still think this would work best as an extension to
Solaris Syminfo?

To be honest I have a problem with that given that Syminfo is a target specific
extension to ELF (which just happens to be implemented in a generic way in
Readelf), and we want to add symbol meta-information as a generic extension
to ELF.

There's no advantage to building upon Syminfo in Binutils given the
implementation is limited to readelf dumping the Syminfo table.

If Syminfo was already part of the gABI I would be on board with working from
that to add the new functionality.

I guess the other option is to take Syminfo, extend it with the new
functionality we want, then propose it as generic ELF extension. I wonder if
there would be legal issues doing all that without any input from Oracle.

Do they "own" the spec? Would I be able to propose their spec with some
extensions to ELF gABI? (These are somewhat rhetorical questions...)

Regards,
Jozef
> 
> > But there are more caveats given that I've worked from a spec which has been
> > followed for an implementation in Clang/LLVM, so if in Binutils we base the
> > symbol meta-information functionality off Solaris syminfo we lose compatibility
> > with this other tool.
> >
> > Even though adding the above si_value field would meet the *general* need of
> > the new implementation, the implementation details between the syminfo and
> > symbol meta-information are very different.
> >
> > I do understand the desire not to fragment Binutils with multiple
> > implementations of similar functionality.
> >
> > If this will be a sticking point for upstreaming then I will need to consider
> > some other options. A key aim of the upstreaming effort of this functioniality
> > is that the GNU and Clang/LLVM implementations are compatible.
> >
> > Thanks,
> > Jozef  
> 
> 
> 

  reply	other threads:[~2020-02-18 18:55 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-02-18 10:25 Jozef Lawrynowicz
2020-02-18 12:58 ` H.J. Lu
2020-02-18 13:47   ` Jozef Lawrynowicz
2020-02-18 13:59     ` H.J. Lu
2020-02-18 14:39       ` Jozef Lawrynowicz
2020-02-18 14:51         ` H.J. Lu
2020-02-18 18:55           ` Jozef Lawrynowicz [this message]
2020-02-18 21:43             ` H.J. Lu

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=20200218185454.056abc91@jozef-kubuntu \
    --to=jozef.l@mittosystems.com \
    --cc=binutils@sourceware.org \
    --cc=hjl.tools@gmail.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).