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

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

On Mon, Aug 31, 2020 at 02:23:57PM +0200, Florian Weimer wrote:
> * Jozef Lawrynowicz:
> 
> > I wonder if it is appropriate for inclusion in the GNU gABI or if we
> > should just add it to a processor-specific ABI. However, it is being
> > used downstream for MSP430 and ARM targets, in GCC and Clang/LLVM
> > respectively. So we'd like to have it standardized somewhere generic
> > so that different targets and toolchains can align on it.
> 
> Is there an expectation to upstream these changes?  In the present state
> there does not seem to be need for such coordination.

Yes, one way or another I will upstream the functionality to the GNU
toolchain, as an MSP430-specific feature if that is what ends up being
the only approved route.

TI are also looking to upstream their ARM Clang/LLVM implementation.

I posted an RFC for an initial version of the functionality to Binutils
back in February, but H.J. Lu pointed out that discussions about ELF
extensions should be had on the ELF gABI mailing list.
https://sourceware.org/pipermail/binutils/2020-February/110236.html

So I've been looking for where best to place this functionality before
finalizing the spec and implementation.

The functionality has been improved and extended since then, I would say
the initial version is generally ready for upstreaming after a bit of
additional tidying.

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

When code size is a concern, we'd always avoid using C++ for a library.

The user would probably rather just manually choose the correct printf
function by defining a symbol at link time than take on the C++ burden
of having it done automatically.

Below I've included some additional clarifications on SMT_PRINTF_FMT that
came up from the discussions on the ELF gABI mailing list.

Thanks,
Jozef

> 
> Thanks,
> Florian
> 

---
On Thu, Aug 27, 2020 at 08:43:56PM +0000, Joseph Myers wrote:
> I think this is rather under-specified.  A format conversion specification
> has six parts in ISO C: the initial '%', any flags, any field width, any
> precision, any length modifier, the conversion specifier character.  
> POSIX extends this by allowing the initial '%' to be of the form '%n$'
> instead to specify the position of the argument converted, and also allows
> '*m$' as a form of width and precision, similarly.
>
> Do you intend the .strtab_meta entry to contain all those parts of the
> conversion specification, or only some of them?

The intention would be to omit any digits used by the width and
precision specifiers, and the '.' used by the precision specifier,
but otherwise store all parts of the format string, de-duplicating
parts of it as necessary.

The exact behavior of how to encode the format string certainly does need
clearer specification. '%' doesn't actually need to be stored in the condensed
string, so the behavior should instead be like the below examples:

printf ("%-*.*hhd %#hx", ...);
  yields the following NUL terminated string
-*hhd#hx

printf ("%+ld % 8.8lld %-6.6lld", ...);
  yields the following NUL terminated string
+ld lld-

printf ("%*2$.*3$lld %4$*5$.*6$ld", ...);
  yields the following NUL terminated string
*$lldld

It's assumed that the number of the positional argument used with "%n$"
or "*m$" isn't important, but the presence of '$' is required as it
indicates an additional feature which might need to be supported by
printf.

There also needs to be a clarification on how to group the parts of the
format string when performing the de-duplication. For example,
"%ld %lld %lf" should *not* be condensed into "ldllf", as the linker may
want to know which length modifier is used by a given conversion format
specifier. Instead it should be condensed to "ldlldlf".

  The length modifier and format specifier are considered an atomic part
  of the format string for the purposes of de-duplication.