[RFC] Proposal for new ELF extension - "Symbol meta-information"
Florian Weimer
fweimer@redhat.com
Tue Sep 1 12:48:04 GMT 2020
* 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.
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.
Thanks,
Florian
More information about the Gnu-gabi
mailing list