Re: [PATCH v2] elf: Support DT_RELR relative relocation format [BZ #27924]

["H.J. Lu" <hjl.tools@gmail.com>]

On Mon, Oct 18, 2021 at 4:44 PM Joseph Myers <joseph@codesourcery.com> wrote:
>
> On Mon, 18 Oct 2021, H.J. Lu via Libc-alpha wrote:
>
> > Ideally when the new specifiers are used, it should require the new
> > glibc version.  Is there a way to do it?
>
> I don't think there's any sensible way to do it.  You'd need new symbol
> versions (aliased to the old ones, not actual separate entry points with
> different addresses) for all the 70 or so printf-like functions (twice
> that number when two long double variants are supported, three times that
> number when three long double variants are supported).  That's not
> something we've done before for new printf/scanf/strftime/strfmon formats.
>
> The scanf changes will get new __isoc23_* entry points because of API
> differences with scanf %i (but someone could still e.g. use scanf %b when
> building for strict C11, and so get a binary using the old entry point
> with a new format that doesn't work with older glibc - there would only be
> the 32 / 44 / 56 new entry points, not new symbol versions for old entry
> points).
>

On glibc 2.34 machine:

[hjl@gnu-snb-1 tmp]$ cat x.c
#include <stdio.h>

int
main ()
{
  printf ("hello\n");
  return 0;
}
[hjl@gnu-snb-1 tmp]$ cat v.S
.section .data.retain,"awR",%progbits
.dc.a GLIBC_2.34
[hjl@gnu-snb-1 tmp]$ gcc v.S x.c
[hjl@gnu-snb-1 tmp]$ ./a.out
hello
[hjl@gnu-snb-1 tmp]$

Copy it to glibc 2.33 machine:

[hjl@gnu-cfl-1 tmp]$ ./a.out
./a.out: /lib64/libc.so.6: version `GLIBC_2.34' not found (required by ./a.out)
[hjl@gnu-cfl-1 tmp]$

Does glibc built by lld have glibc versions in the dynamic symbol table?
If not, lld can't be used to generate glibc.

-- 
H.J.