Proposal: Replace xstat (stat version dispatcher)

Proposal: Replace xstat (stat version dispatcher)

[Florian Weimer]

We currently have this (in <sys/stat.h>)

/* To allow the `struct stat' structure and the file type `mode_t'
   bits to vary without changing shared library major version number,
   the `stat' family of functions and `mknod' are in fact inline
   wrappers around calls to `xstat', `fxstat', `lxstat', and `xmknod',
   which all take a leading version-number argument designating the
   data structure and bits used.  <bits/stat.h> defines _STAT_VER with
   the version number corresponding to `struct stat' as defined in
   that file; and _MKNOD_VER with the version number corresponding to
   the S_IF* macros defined therein.  It is arranged that when not
   inlined these function are always statically linked; that way a
   dynamically-linked executable always encodes the version number
   corresponding to the data structures it uses, so the `x' functions
   in the shared library can adapt without needing to recompile all
   callers.  */

and (in io/stat.c):

/* This definition is only used if inlining fails for this function; see
   the last page of <sys/stat.h>.  The real work is done by the `x'
   function which is passed a version number argument.  We arrange in the
   makefile that when not inlined this function is always statically
   linked; that way a dynamically-linked executable always encodes the
   version number corresponding to the data structures it uses, so the `x'
   functions in the shared library can adapt without needing to recompile
   all callers.  */

Should we switch this over to symbol versioning, with definitions for
the stat, fstat, &c functions in libc.so.6?

Thanks,
Florian

Re: Proposal: Replace xstat (stat version dispatcher)

[Joseph Myers]

On Mon, 17 Dec 2018, Florian Weimer wrote:

> Should we switch this over to symbol versioning, with definitions for
> the stat, fstat, &c functions in libc.so.6?

I think we should (for both stat and mknod functions - and thus use only 
the new mechanism for time64 variants of stat functions).  If the type 
layouts do change in future, using symbol versioning would be friendlier 
to users than the existing mechanism (it would mean binaries requiring the 
new layout reference the new symbol versions and so obviously need a new 
glibc version, rather than only failing at runtime because they pass a new 
version number to the __x* functions) - though as usual with such changes 
users may dislike building with a new glibc introducing requirements on a 
new symbol version even though they're only using old functions (users in 
such cases should be building using an old-glibc sysroot if they don't 
want new-glibc dependencies, but don't always do so).

Internal glibc code would need to change to use the stat64 etc. interfaces 
directly (should always use the *64 variants) rather than __x*, with due 
allowance for namespace issues (if these apply in libraries outside libc, 
it's possible some __*64 variants will need exporting - arguably they 
should be exported at public symbol versions anyway, as per bug 14106).

-- 
Joseph S. Myers
joseph@codesourcery.com

Re: Proposal: Replace xstat (stat version dispatcher)

[Florian Weimer]

* Joseph Myers:

> On Mon, 17 Dec 2018, Florian Weimer wrote:
>
>> Should we switch this over to symbol versioning, with definitions for
>> the stat, fstat, &c functions in libc.so.6?
>
> I think we should (for both stat and mknod functions - and thus use only 
> the new mechanism for time64 variants of stat functions).

Okay, I'll look at this in late winter then.

> If the type layouts do change in future, using symbol versioning would
> be friendlier to users than the existing mechanism (it would mean
> binaries requiring the new layout reference the new symbol versions
> and so obviously need a new glibc version, rather than only failing at
> runtime because they pass a new version number to the __x* functions)
> - though as usual with such changes users may dislike building with a
> new glibc introducing requirements on a new symbol version even though
> they're only using old functions (users in such cases should be
> building using an old-glibc sysroot if they don't want new-glibc
> dependencies, but don't always do so).

We still have such a bump coming up for bug 23323, so maybe we can
tackle both in the 2.30 cycle.

Thanks,
Florian