Re: __xstat et al. as compat symbols

[Florian Weimer via Libc-alpha <libc-alpha@sourceware.org>]

* Adhemerval Zanella:

> On 21/10/2020 02:21, Florian Weimer wrote:
>> * Adhemerval Zanella via Libc-alpha:
>> 
>>> diff --git a/sysdeps/unix/sysv/linux/alpha/fxstat64.c b/sysdeps/unix/sysv/linux/alpha/fxstat64.c
>>> index 9d6b8eca32..bcfb55050c 100644
>>> --- a/sysdeps/unix/sysv/linux/alpha/fxstat64.c
>>> +++ b/sysdeps/unix/sysv/linux/alpha/fxstat64.c
>>> @@ -22,9 +22,11 @@
>>>  #include <kernel_stat.h>
>>>  #include <sysdep.h>
>>>  #include <xstatconv.h>
>>> +#include <shlib-compat.h>
>>>  
>>>  /* Get information about the file NAME in BUF.  */
>>>  int
>>> +attribute_compat_text_section
>>>  __fxstat64 (int vers, int fd, struct stat64 *buf)
>>>  {
>>>    switch (vers)
>>> @@ -42,4 +44,12 @@ __fxstat64 (int vers, int fd, struct stat64 *buf)
>>>        }
>>>      }
>>>  }
>>> -strong_alias (__fxstat64, __fxstat);
>>> +
>>> +#if SHLIB_COMPAT(libc, GLIBC_2_0, GLIBC_2_33)
>>> +strong_alias (__fxstat64, __fxstat_compat)
>>> +compat_symbol (libc, __fxstat_compat, __fxstat, GLIBC_2_0);
>>> +#endif
>>> +
>>> +#if SHLIB_COMPAT(libc, GLIBC_2_1, GLIBC_2_33)
>>> +compat_symbol (libc, __fxstat64, __fxstat64, GLIBC_2_1);
>>> +#endif
>> 
>> This change breaks a lot of static libraries out there.  Do we really
>> want to do this immediately, or should we just stop using these symbols
>> from libc_nonshared.a, and defer the compat symbol treatment to a future
>> glibc version?
>
> This is the similar the libm finite symbols where my understanding was
> user was supposed to rebuild the library.

I think the impact of that is a bit narrower because it requires special
compiler flags.  But I suspect I will ask for reverting that in a year
as well. 8-/

> The issue is only for static linking, by stopping using
> libc_nonshared.a we need to provide the versioned stat symbols anyway.
> And we still need to handle new ABIs where adding the old xstat
> symbols does not make sense (such as riscv32 or any new 32-bit
> architecture).

You could use a SHLIB_COMPAT conditional without compat_symbol, the two
are separate.

> It would required a new compat_symbol directive to export the symbols
> *just* for static linking and some building tinkering to just build
> the xstat symbol for dynamic object and static linking depending of
> support ABI version.

The problem is not relying on the contents of libc_nonshared.a, that is
working still.  It's code that calls __xstat et al. directly via the old
inline functions in the headers.

> If we just defer the compat move, it would add the needless symbols on
> newer ABIs that we will need to keep supporting indefinitely (even
> though they won't be used anywhere unless user explicily links against
> a protected symbol) and we would eventually need to handle the y2038
> support on old ABIs (with the _TIME_SIZE selection) by either adding
> proper 64-bit time support for by removing the xstat for good.

See above, we can (and should) remove it on newer ABIs only.

Thanks,
Florian
-- 
Red Hat GmbH, https://de.redhat.com/ , Registered seat: Grasbrunn,
Commercial register: Amtsgericht Muenchen, HRB 153243,
Managing Directors: Charles Cachera, Brian Klemm, Laurie Krebs, Michael O'Neill