Re: [RFC] Symbol meta-information ELF extension

[Jozef Lawrynowicz <jozef dot l at mittosystems dot com>]

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;

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