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

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

On Tue, Sep 01, 2020 at 01:20:16PM +0200, Florian Weimer via Gnu-gabi wrote:
> * 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.

I am not against removing SMT_PRINTF_FMT as a generic metainfo type,
since it is not necessarily the most straightforward way to achieve the desired
behavior.
TI are using it in conjunction with another vendor-specific metainfo type which
tries to work out the format-specifiers used by a printf() call which has
a non-constant string used for the format argument.

So perhaps SMT_PRINTF_FMT is only really required when used with that
other type which requires visibility of the full program, not individual
compilation units.

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:

  printf_double (const char *fmt, ...)
  {
    return printf_generic (...);
  }

  printf_generic (const char *fmt, ...)
  {
    if (printf_double != 0)      /* Check for compiler emitted symbol.  */
      return printf_double_1 (...)  /* Call real worker function.  */
    else if (printf_float != 0)
      return printf_float_1 (...)
    else if (printf_int != 0)
      return printf_int_1 (...)
      ....
  }

Do you have any opinions on the inclusion of the symbol meta-information
mechanism itself within the GNU gABI?

Thanks,
Jozef

> 
> Thanks,
> Florian
>