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

[Florian Weimer]

* James Y. Knight via Gnu-gabi:

> On Mon, Aug 31, 2020 at 8:24 AM Florian Weimer via Gnu-gabi <
> gnu-gabi@sourceware.org> wrote:
>
>> >     3.3.3 SMT_PRINTF_FMT use case
>>
>> Can this achieved in C++ with a library-only solution?  So that
>>   printf ("%s", str);
>> and
>>   printf ("%f", num);
>> resolve to different printf symbols externally?
>>
>
> The LLVM backend optimizer already does this automatically for XCore, TCE,
> and Emscripten targets, without interrogating the format string, or adding
> anything to the object format.
>
> On all three: if there are no floating-point arguments to the call, it will
> translate {s,f,}printf -> i{s,f,}printf. Otherwise, on emscripten only, if
> there are no 128-bit float arguments, it will translate {s,f,}printf ->
> small_{s,f,}printf

It's not what I had in mind with my C++ comment (I thought about using a
constexpr construct to parse the format strings), but it's simpler to
just look at the types.

I think we could guide this by some attribute machinery for C,
especially if it is completely type-dependent.  If the symbol choice is
determined by that, it is not necessary to maintain the symbol selection
in very different places (the library implementation *and* the linker).
This is main thing I do not like about SMT_PRINTF_FMT: it needs very
library-specific code in the link editor.

Thanks,
Florian