[RFC] Proposal for new ELF extension - "Symbol meta-information"

[Jozef Lawrynowicz]

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