[v2] Move some chown / lchown / fchown definitions to syscalls.list (bug 14138)

[Stefan Liebler]

Hi,

i have tested this patch on s390.
Before this patch, the symbol lchown@@GLIBC_2.0 was weak. Now it is global.
Changing the corresponding line in syscalls.list to
"lchown        -    lchown32    i:sii    __lchown    lchown chown@GLIBC_2.0"
leads to the weak symbol.

Bye
Stefan

On 10/07/2014 01:22 AM, Joseph S. Myers wrote:
> (This is an updated version of
> <https://sourceware.org/ml/libc-alpha/2014-09/msg00546.html>, for the
> architectures for which that has not been reviewed, combined with the
> parts of <https://sourceware.org/ml/libc-alpha/2014-09/msg00559.html>
> related to chown for those architectures.  I've committed the reviewed
> parts of the first patch and the parts of the second patch not
> depending on unreviewed parts of the first.  i386, s390, sh and sparc
> changes have not been reviewed so far.)
>
> Continuing the move of syscall definitions to syscalls.list, where the
> removal of support for old kernel versions has made this possible,
> this patch moves various definitions of chown, lchown and fchown.
>
> In most cases the need for special syscalls.list entries (rather than
> existing generic ones) is because these architectures use chown32,
> lchown32 and fchown32 as syscall names.  Some architectures also have
> symbol versioning compatibility for older versions of chown having
> been equivalent to lchown.
>
> The aliases specified for s390-32 had the effect of exporting
> __chown@@GLIBC_2.1 (but not __chown@GLIBC_2.0) despite it not being
> listed in Versions files.  (I'm not sure why versioned_symbol but not
> compat_symbol were effective like that to create such __chown exports
> in the absence of Versions entries.)  The natural way to preserve that
> versioned export of __chown seems to be to add it in a Versions file,
> so I did so.  (Maybe actually it should be a compat symbol,
> __chown@GLIBC_2.1, unless there's a good reason for that export, but
> this patch doesn't change anything there.)
>
> Tested for x86.