This is the mail archive of the binutils@sourceware.org mailing list for the binutils project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [RFC] Symbol meta-information ELF extension


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

> 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



-- 
H.J.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]