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

[Jozef Lawrynowicz <jozef.l@mittosystems.com>]

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.

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

Some standardization of parallel symbol tables would certainly be
forward thinking and enable future extensions which use parallel symbol
tables to be kept in sync with .symtab, even if those older tools don't
understand the extension itself.

If we also consider SMT_NOINIT removed as a generic metainfo type, based
on the feedback received from the ELF gABI discussions, then that leaves
the SMT_RETAIN and SMT_LOCATION metainfo types.

These types in particular generally operate on the section level,
at least, the behavior the linker will eventually
apply will be to the containing section, not the symbol itself.

So they could be implemented using new section flags (sh_flags).
There is plenty of space for additional sh_flags (unlike symbol
flags).

- SMT_RETAIN
  The linker will only garbage collect sections, not individual
  symbols.
  A new section flag indicates that the section should be retained
  by the linker, even if it would be garbage collected. 
  Whatever section contains the symbol that the "retain"
  attribute is applied to will have the "retain" sh_flags bit set.

- SMT_LOCATION
  The linker can only place sections at a specific address,
  not individual symbols.
  A new section flag indicates that the section should be placed at a
  specific VMA in the executable file by the linker.
  The address could be set in the sh_addr field, or encoded in the
  section name.

Since the overall aim is to support the "retain" and "location" C/C++
attributes, perhaps this is the most appropriate way forward...

Thanks,
Jozef