Linux 5.9 has one new syscall, close_range. Update syscall-names.list
and regenerate the arch-syscall.h headers with build-many-glibcs.py
update-syscalls.
Tested with build-many-glibcs.py.
This patch removes the mknod and mknodat static wrapper and add the
symbols on the libc with the expected names.
Both the prototypes of the internal symbol linked by the static
wrappers and the inline redirectors are also removed from the installed
sys/stat.h header file. The wrapper implementation license LGPL
exception is also removed since it is no longer statically linked to
binaries.
Internally the _STAT_VER* definitions are moved to the arch-specific
xstatver.h file.
Checked with a build for all affected ABIs. I also checked on x86_64,
i686, powerpc, powerpc64le, sparcv9, sparc64, s390, and s390x.
Reviewed-by: Lukasz Majewski <lukma@denx.de>
This patch removes the stat, stat64, lstat, lstat64, fstat, fstat64,
fstatat, and fstatat64 static wrapper and add the symbol on the libc
with the expected names.
Both the prototypes of the internal symbol linked by the static
wrappers and the inline redirectors are also removed from the installed
sys/stat.h header file. The wrapper implementation license LGPL
exception is also removed since it is no longer statically linked to
binaries.
Internally the _STAT_VER* definitions are moved to a arch-specific
xstatver.h file. The internal defines that redirects internals
{f}stat{at} to their {f}xstat{at} counterparts are removed for Linux
(!NO_RTLD_HIDDEN). Hurd still requires them since {f}stat{at} pulls
extra objects that makes the loader build fail otherwise (I haven't
dig into why exactly).
Checked with a build for all affected ABIs. I also checked on x86_64,
i686, powerpc, powerpc64le, sparcv9, sparc64, s390, and s390x.
Reviewed-by: Lukasz Majewski <lukma@denx.de>
The generic version does not have time64 support and Linux default
uses utimensat. With hppa version gone, __ASSUME_UTIMES is not used
anymore.
Checked on x86_64-linux-gnu and i686-linux-gnu (on 5.4 and on 4.15
kernel).
Reviewed-by: Alistair Francis <alistair.francis@wdc.com>
This patch adds the ABI-related bits to reflect the new mallinfo2
function, and adds a test case to verify basic functionality.
Reviewed-by: Adhemerval Zanella <adhemerval.zanella@linaro.org>
The LFS support is implemented on fxstat64.c, instead of fxstat.c for
64-bit architectures. The fxstatat.c implements the non-LFS and it is
a no-op for !XSTAT_IS_XSTAT64.
The generic non-LFS implementation handles two cases:
1. New kABIs which uses generic pre 64-bit time Linux ABI (csky and
nios): it issues __NR_fstatat64 plus handle the overflow on st_ino,
st_size, or st_blocks. It only handles _STAT_VER_KERNEL.
2. Old kABIs with old non-LFS support (arm, i386, hppa, m68k, mips32,
microblaze, s390, sh, powerpc, and sparc32). it issues
__NR_fstatat64 and convert to non-LFS stat struct based on the
version.
Also non-LFS mips64 is an outlier and it has its own implementation
since _STAT_VER_LINUX requires a different conversion function (it
uses the kernel_stat as the sysissues argument since its exported ABI
is different than the kernel one for both non-LFS and LFS
implementation).
The generic LFS implementation handles multiple cases:
1. XSTAT_IS_XSTAT64 being 1:
1.1. 64-bit kABI (aarch64, ia64, powerpc64*, s390x, riscv64, and
x86_64): it issues __NR_newfstatat for _STAT_VER_KERNEL or
_STAT_VER_LINUX.
1.2. 64-bit kABI outlier (sparc64): it issuess fstatat64 with a
temporary stat64 and convert to output stat64 based on the
input version (and using a sparc64 specific __xstat32_conv).
1.3. New 32-bit kABIs with only 64-bit time_t support (arc and
riscv32): it issues __NR_statx and covert to struct stat64.
2. Old ABIs with XSTAT_IS_XSTAT64 being 0 (arm, csky, i386, hppa, m68k,
microblaze, mips32, nios2, sh, powerpc32, and sparc32): it issues
__NR_fstat64.
Also, two special cases requires specific implementations:
1. alpha: it uses the __NR_fstatat64 syscall instead.
2. mips64: as for non-LFS implementation its ABIs differ from
glibc exported one, which requires an specific conversion
function to handle the kernel_stat.
Checked with a build for all affected ABIs. I also checked on x86_64,
i686, powerpc, powerpc64le, sparcv9, sparc64, s390, and s390x.
Reviewed-by: Lukasz Majewski <lukma@denx.de>
The LFS support is implemented on fxstat64.c, instead of fxstat.c for
64-bit architectures. The fxstat.c implements the non-LFS and it is
a no-op for !XSTAT_IS_XSTAT64.
The generic non-LFS implementation handles two cases:
1. New kABIs which uses generic pre 64-bit time Linux ABI (csky and
nios): it issuess __NR_fstat64 plus handle the overflow on st_ino,
st_size, or st_blocks. It only handles _STAT_VER_KERNEL.
2. Old KABIs with old non-LFS support (arm, i386, hppa, m68k,
microblaze, s390, sh, powerpc, and sparc32). For _STAT_VER_KERNEL
it issues __NR_fstat, otherwise it calls __NR_fstat64 and convert
to non-LFS stat struct and handle possible overflows on st_ino,
st_size, or st_blocks.
Also non-LFS mips is an outlier and it has its own implementation since
_STAT_VER_LINUX requires a different conversion function (it uses the
kernel_stat as the sysissues argument since its exported ABI is
different than the kernel one for both non-LFS and LFS implementation).
The generic LFS implementation handles multiple cases:
1. XSTAT_IS_XSTAT64 being 1:
1.1. 64-bit kABI (aarch64, ia64, powerpc64*, s390x, riscv64, and
x86_64): it issuess __NR_fstat for _STAT_VER_KERNEL or
_STAT_VER_LINUX.
1.2. Old 64-bit kABI with defines __NR_fstat64 instead of __NR_fstat
(sparc64): it issues __NR_fstat for _STAT_VER_KERNEL or
__NR_fstat64 and convert to struct stat64.
1.3. New 32-bit kABIs with only 64-bit time_t support (arc and
riscv32): it issuess __NR_statx and covert to struct stat64.
2. Old ABIs with XSTAT_IS_XSTAT64 being 0 (arm, csky, i386, hppa,
m68k, microblaze, mips32, nios2, sh, powerpc32, and sparc32): it
issues __NR_fstat64.
Also, two special cases requires specific implementations:
1. alpha: it requires to handle _STAT_VER_KERNEL64 to issues
__NR_fstat64 and use the kernel_stat with __NR_fstat otherwise.
2. mips64: as for non-LFS implementation its ABIs differ from
glibc exported one, which requires an specific conversion
function to handle the kernel_stat.
Checked with a build for all affected ABIs. I also checked on x86_64,
i686, powerpc, powerpc64le, sparcv9, sparc64, s390, and s390x.
Reviewed-by: Lukasz Majewski <lukma@denx.de>
The LFS support is implemented on lxstat64.c, instead of lxstat.c for
64-bit architectures. The xstat.c implements the non-LFS and it is
a no-op for !XSTAT_IS_XSTAT64.
The generic non-LFS implementation handles two cases:
1. New kABIs which uses generic pre 64-bit time Linux ABI (csky and
nios): it issues __NR_fstat64 with AT_SYMLINK_NOFOLLOW plus handles
the possible overflow off st_ino, st_size, or st_blocks. It only
handles _STAT_VER_KERNEL.
2. Old KABIs with old non-LFS support (arm, i386, hppa, m68k,
microblaze, s390, sh, powerpc, and sparc32). For _STAT_VER_KERNEL
it issues __NR_lstat, otherwise it isseus __NR_lstat64 and convert
to non-LFS stat struct and handle possible overflows on st_ino,
st_size, or st_blocks.
Also non-LFS mips is an outlier and it has its own implementation since
_STAT_VER_LINUX requires a different conversion function (it uses the
kernel_stat as the syscall argument since its exported ABI is different
than the kernel one for both non-LFS and LFS implementation).
The generic LFS implementation handles multiple cases:
1. XSTAT_IS_XSTAT64 being 1:
1.1. Old 64-bit kABI (ia64, powerpc64*, s390x, sparc64, x86_64): it
issues __NR_lstat for _STAT_VER_KERNEL or _STAT_VER_LINUX.
1.2. Old 64-bit kABI with defines __NR_lstat64 instead of __NR_lstat
(sparc64): it issues __NR_lstat for _STAT_VER_KERNEL or
__NR_lstat64 and convert to struct stat64.
1.3. New kABIs which uses generic 64-bit Linux ABI (aarch64 and
riscv64): it issues __NR_newfstatat with AT_SYMLINK_NOFOLLOW
and only for _STAT_VER_KERNEL.
1.4. New 32-bit kABIs with only 64-bit time_t support (arc and
riscv32): it issues __NR_statx and covert to struct stat64.
2. Old ABIs with XSTAT_IS_XSTAT64 being 0:
2.1. New kABIs which uses generic pre 64-bit time Linux ABI (csky
and nios2): it issues __NR_fstatat64 for _STAT_VER_KERNEL.
2.2. Old kABIs with old non-LFS support (arm, i386, hppa, m68k,
microblaze, s390, sh, mips32, powerpc32, and sparc32): it
issues __NR_lstat64.
Also, two special cases requires specific LFS implementations:
1. alpha: it requires to handle _STAT_VER_KERNEL64 to issue
__NR_lstat64 and use the kernel_stat with __NR_lstat otherwise.
2. mips64: as for non-LFS implementation its ABIs differ from
glibc exported one, which requires a specific conversion
function to handle the kernel_stat.
Checked with a build for all affected ABIs. I also checked on x86_64,
i686, powerpc, powerpc64le, sparcv9, sparc64, s390, and s390x.
Reviewed-by: Lukasz Majewski <lukma@denx.de>
The LFS support is implemented on xstat64.c, instead of xstat.c for
64-bit architectures. The xstat.c implements the non-LFS it is
no-op for !XSTAT_IS_XSTAT64.
The generic non-LFS implementation handle two cases:
1. New kABIs which uses generic pre 64-bit time Linux ABI (csky and
nios): it issues __NR_fstat64 plus handle the overflow on st_ino,
st_size, or st_blocks. It only handles _STAT_VER_KERNEL.
2. Old KABIs with old non-LFS support (arm, i386, hppa, m68k,
microblaze, s390, sh, powerpc, and sparc32). For _STAT_VER_KERNEL
it issues __NR_stat, otherwise it issues __NR_stat64 and convert
to non-LFS stat struct handling possible overflows on st_ino,
st_size, or st_blocks.
Also the non-LFS mips is an outlier and it has its own implementation
since _STAT_VER_LINUX requires a different conversion function (it uses
the kernel_stat as the syscall argument since its exported ABI is
different than the kernel one for both non-LFS and LFS implementation).
The generic LFS implementation handles multiple cases:
1. XSTAT_IS_XSTAT64 being 1:
1.1. Old 64-bit kABI (ia64, powerpc64*, s390x, x86_64): it
issues __NR_stat for _STAT_VER_KERNEL or _STAT_VER_LINUX.
1.2. Old 64-bit kABI with defines __NR_stat64 instead of __NR_stat
(sparc64): it issues __NR_stat for _STAT_VER_KERNEL or
__NR_stat64 and convert to struct stat64.
1.3. New kABIs which uses generic 64-bit Linux ABI (aarch64 and
riscv64): it issues __NR_newfstatat and only for
_STAT_VER_KERNEL.
1.4. New 32-bit kABIs with only 64-bit time_t support (arc and
riscv32): it issues __NR_statx and covert to struct stat64.
2. Old ABIs with XSTAT_IS_XSTAT64 being 0:
2.1. New kABIs which uses generic pre 64-bit time Linux ABI (csky
and nios2): it issues __NR_fstatat64 for _STAT_VER_KERNEL.
2.2. Old kABIs with old non-LFS support (arm, i386, hppa, m68k,
microblaze, s390, sh, mips32, powerpc32, and sparc32): it
issues __NR_stat64.
Also, two special cases requires specific LFS implementations:
1. alpha: it requires to handle _STAT_VER_KERNEL64 to call __NR_stat64
or use the kernel_stat with __NR_stat otherwise.
2. mips64: as for non-LFS implementation its ABIs differ from glibc
exported one, which requires an specific conversion function to
handle the kernel_stat.
Checked with a build for all affected ABIs. I also checked on x86_64,
i686, powerpc, powerpc64le, sparcv9, sparc64, s390, and s390x.
Reviewed-by: Lukasz Majewski <lukma@denx.de>
It indicates that the glibc export stat64 is similar in size and
layout of the kernel stat64 used on the syscall. It is not currently
used on stat implementation, but the idea is to indicate whether
to use the kernel_stat to issue on the syscall on the *stat*64
variant (more specifically on mips which its exported ABI does not
match the kernel).
Reviewed-by: Lukasz Majewski <lukma@denx.de>
Linux 5.8 has one new syscall, faccessat2. Update syscall-names.list
and regenerate the arch-syscall.h headers with build-many-glibcs.py
update-syscalls.
Tested with build-many-glibcs.py.
The kernel ABI is not finalized, and there are now various proposals
to change the size of struct rseq, which would make the glibc ABI
dependent on the version of the kernels used for building glibc.
This is of course not acceptable.
This reverts commit 48699da1c4 ("elf:
Support at least 32-byte alignment in static dlopen"), commit
8f4632deb3 ("Linux: rseq registration
tests"), commit 6e29cb3f61 ("Linux: Use
rseq in sched_getcpu if available"), and commit
0c76fc3c2b ("Linux: Perform rseq
registration at C startup and thread creation"), resolving the conflicts
introduced by the ARC port and the TLS static surplus changes.
Reviewed-by: Carlos O'Donell <carlos@redhat.com>
To provide a y2038 safe interface a new symbol __shmctl64 is added
and __shmctl is change to call it instead (it adds some extra buffer
copying for the 32 bit time_t implementation).
Two new structures are added:
1. kernel_shmid64_ds: used internally only on 32-bit architectures
to issue the syscall. A handful of architectures (hppa, i386,
mips, powerpc32, and sparc32) require specific implementations
due to their kernel ABI.
2. shmid_ds64: this is only for __TIMESIZE != 64 to use along with
the 64-bit shmctl. It is different than the kernel struct because
the exported 64-bit time_t might require different alignment
depending on the architecture ABI.
So the resulting implementation does:
1. For 64-bit architectures it assumes shmid_ds already contains
64-bit time_t fields and will result in just the __shmctl symbol
using the __shmctl64 code. The shmid_ds argument is passed as-is
to the syscall.
2. For 32-bit architectures with default 64-bit time_t (newer ABIs
such riscv32 or arc), it will also result in only one exported
symbol but with the required high/low time handling.
3. Finally for 32-bit architecture with both 32-bit and 64-bit time_t
support we follow the already set way to provide one symbol with
64-bit time_t support and implement the 32-bit time_t support
using of the 64-bit one.
The default 32-bit symbol will allocate and copy the shmid_ds
over multiple buffers, but this should be deprecated in favor
of the __shmctl64 anyway.
Checked on i686-linux-gnu and x86_64-linux-gnu. I also did some sniff
tests on powerpc, powerpc64, mips, mips64, armhf, sparcv9, and
sparc64.
Reviewed-by: Alistair Francis <alistair.francis@wdc.com>
Tested-by: Alistair Francis <alistair.francis@wdc.com>
Tested-by: Carlos O'Donell <carlos@redhat.com>
Reviewed-by: Carlos O'Donell <carlos@redhat.com>
Each architecture overrides the struct msqid_ds which its required
kernel ABI one.
Checked on x86_64-linux-gnu and some bases sysvipc tests on hppa,
mips, mipsle, mips64, mips64le, sparc64, sparcv9, powerpc64le,
powerpc64, and powerpc.
Reviewed-by: Alistair Francis <alistair.francis@wdc.com>
Tested-by: Alistair Francis <alistair.francis@wdc.com>
Tested-by: Carlos O'Donell <carlos@redhat.com>
Reviewed-by: Carlos O'Donell <carlos@redhat.com>
To provide a y2038 safe interface a new symbol __msgctl64 is added
and __msgctl is change to call it instead (it adds some extra buffer
coping for the 32 bit time_t implementation).
Two new structures are added:
1. kernel_msqid64_ds: used internally only on 32-bit architectures
to issue the syscall. A handful of architectures (hppa, i386, mips,
powerpc32, and sparc32) require specific implementations due to
their kernel ABI.
2. msqid_ds64: this is only for __TIMESIZE != 64 to use along with
the 64-bit msgctl. It is different than the kernel struct because
the exported 64-bit time_t might require different alignment
depending on the architecture ABI.
So the resulting implementation does:
1. For 64-bit architectures it assumes msqid_ds already contains
64-bit time_t fields and will result in just the __msgctl symbol
using the __msgctl64 code. The msgid_ds argument is passed as-is
to the syscall.
2. For 32-bit architectures with default 64-bit time_t (newer ABIs
such riscv32 or arc), it will also result in only one exported
symbol but with the required high/low time handling.
3. Finally for 32-bit architecture with both 32-bit and 64-bit time_t
support we follow the already set way to provide one symbol with
64-bit time_t support and implement the 32-bit time_t support using
the 64-bit time_t.
The default 32-bit symbol will allocate and copy the msqid_ds
over multiple buffers, but this should be deprecated in favor
of the __msgctl64 anyway.
Checked on i686-linux-gnu and x86_64-linux-gnu. I also did some sniff
tests on powerpc, powerpc64, mips, mips64, armhf, sparcv9, and
sparc64.
Tested-by: Carlos O'Donell <carlos@redhat.com>
Reviewed-by: Carlos O'Donell <carlos@redhat.com>
Reviewed-by: Alistair Francis <alistair.francis@wdc.com>
Tested-by: Alistair Francis <alistair.francis@wdc.com>
Each architecture overrides the struct msqid_ds which its required
kernel ABI one.
Checked on x86_64-linux-gnu and some bases sysvipc tests on hppa,
mips, mipsle, mips64, mips64le, sparc64, sparcv9, powerpc64le,
powerpc64, and powerpc.
Tested-by: Carlos O'Donell <carlos@redhat.com>
Reviewed-by: Carlos O'Donell <carlos@redhat.com>
Reviewed-by: Alistair Francis <alistair.francis@wdc.com>
Tested-by: Alistair Francis <alistair.francis@wdc.com>
Different than others 64-bit time_t syscalls, the SysIPC interface
does not provide a new set of syscall for y2038 safeness. Instead it
uses unused fields in semid_ds structure to return the high bits for
the timestamps.
To provide a y2038 safe interface a new symbol __semctl64 is added
and __semctl is change to call it instead (it adds some extra buffer
copying for the 32 bit time_t implementation).
Two new structures are added:
1. kernel_semid64_ds: used internally only on 32-bit architectures
to issue the syscall. A handful of architectures (hppa, i386,
mips, powerpc32, sparc32) require specific implementations due
their kernel ABI.
2. semid_ds64: this is only for __TIMESIZE != 64 to use along with
the 64-bit semctl. It is different than the kernel struct because
the exported 64-bit time_t might require different alignment
depending on the architecture ABI.
So the resulting implementation does:
1. For 64-bit architectures it assumes semid_ds already contains
64-bit time_t fields and will result in just the __semctl symbol
using the __semctl64 code. The semid_ds argument is passed as-is
to the syscall.
2. For 32-bit architectures with default 64-bit time_t (newer ABIs
such riscv32 or arc), it will also result in only one exported
symbol but with the required high/low handling.
It might be possible to optimize it further to avoid the
kernel_semid64_ds to semun transformation if the exported ABI
for the architectures matches the expected kernel ABI, but the
implementation is already complex enough and don't think this
should be a hotspot in any case.
3. Finally for 32-bit architecture with both 32-bit and 64-bit time_t
support we follow the already set way to provide one symbol with
64-bit time_t support and implement the 32-bit time_t support
using the 64-bit one.
The default 32-bit symbol will allocate and copy the semid_ds
over multiple buffers, but this should be deprecated in favor
of the __semctl64 anyway.
Checked on i686-linux-gnu and x86_64-linux-gnu. I also did some sniff
tests on powerpc, powerpc64, mips, mips64, armhf, sparcv9, and
sparc64.
Reviewed-by: Alistair Francis <alistair.francis@wdc.com>
Tested-by: Alistair Francis <alistair.francis@wdc.com>
Tested-by: Vineet Gupta <vgupta@synopsys.com>
Reviewed-by: Carlos O'Donell <carlos@redhat.com>
Tested-by: Carlos O'Donell <carlos@redhat.com>
The strerrorname_np returns error number name (e.g. "EINVAL" for EINVAL)
while strerrordesc_np returns string describing error number (e.g
"Invalid argument" for EINVAL). Different than strerror,
strerrordesc_np does not attempt to translate the return description,
both functions return NULL for an invalid error number.
They should be used instead of sys_errlist and sys_nerr, both are
thread and async-signal safe. These functions are GNU extensions.
Checked on x86-64-linux-gnu, i686-linux-gnu, powerpc64le-linux-gnu,
and s390x-linux-gnu.
Tested-by: Carlos O'Donell <carlos@redhat.com>
Reviewed-by: Carlos O'Donell <carlos@redhat.com>
The sigabbrev_np returns the abbreviated signal name (e.g. "HUP" for
SIGHUP) while sigdescr_np returns the string describing the error
number (e.g "Hangup" for SIGHUP). Different than strsignal,
sigdescr_np does not attempt to translate the return description and
both functions return NULL for an invalid signal number.
They should be used instead of sys_siglist or sys_sigabbrev and they
are both thread and async-signal safe. They are added as GNU
extensions on string.h header (same as strsignal).
Checked on x86-64-linux-gnu, i686-linux-gnu, powerpc64le-linux-gnu,
and s390x-linux-gnu.
Tested-by: Carlos O'Donell <carlos@redhat.com>
Reviewed-by: Carlos O'Donell <carlos@redhat.com>
The symbol is deprecated by strerror since its usage imposes some issues
such as copy relocations.
Its internal name is also changed to _sys_errlist_internal to avoid
static linking usage. The compat code is also refactored by removing
the over enginered errlist-compat.c generation from manual entried and
extra comment token in linker script file. It disantangle the code
generation from manual and simplify both Linux and Hurd compat code.
The definitions from errlist.c are moved to errlist.h and a new test
is added to avoid a new errno entry without an associated one in manual.
Checked on x86_64-linux-gnu and i686-linux-gnu. I also run a check-abi
on all affected platforms.
Tested-by: Carlos O'Donell <carlos@redhat.com>
Reviewed-by: Carlos O'Donell <carlos@redhat.com>
It refactor how signals are defined by each architecture. Instead of
include a generic header (bits/signum-generic.h) and undef non-default
values in an arch specific header (bits/signum.h) the new scheme uses a
common definition (bits/signum-generic.h) and each architectures add
its specific definitions on a new header (bits/signum-arch.h).
For Linux it requires copy some system default definitions to alpha,
hppa, and sparc. They are historical values and newer ports uses
the generic Linux signum-arch.h.
For Hurd the BSD signum is removed and moved to a new header (it is
used currently only on Hurd).
Checked on a build against all affected ABIs.
Reviewed-by: Carlos O'Donell <carlos@redhat.com>
Tested-by: Carlos O'Donell <carlos@redhat.com>
The variable is placed in libc.so, and it can be true only in
an outer libc, not libcs loaded via dlmopen or static dlopen.
Since thread creation from inner namespaces does not work,
pthread_create can update __libc_single_threaded directly.
Using __libc_early_init and its initial flag, implementation of this
variable is very straightforward. A future version may reset the flag
during fork (but not in an inner namespace), or after joining all
threads except one.
Reviewed-by: DJ Delorie <dj@redhat.com>
Register rseq TLS for each thread (including main), and unregister for
each thread (excluding main). "rseq" stands for Restartable Sequences.
See the rseq(2) man page proposed here:
https://lkml.org/lkml/2018/9/19/647
Those are based on glibc master branch commit 3ee1e0ec5c.
The rseq system call was merged into Linux 4.18.
The TLS_STATIC_SURPLUS define is increased to leave additional room for
dlopen'd initial-exec TLS, which keeps elf/tst-auditmany working.
The increase (76 bytes) is larger than 32 bytes because it has not been
increased in quite a while. The cost in terms of additional TLS storage
is quite significant, but it will also obscure some initial-exec-related
dlopen failures.
This patch changes the exp10f error handling semantics to only set
errno according to POSIX rules. New symbol version is introduced at
GLIBC_2.32. The old wrappers are kept for compat symbols.
There are some outliers that need special handling:
- ia64 provides an optimized implementation of exp10f that uses ia64
specific routines to set SVID compatibility. The new symbol version
is aliased to the exp10f one.
- m68k also provides an optimized implementation, and the new version
uses it instead of the sysdeps/ieee754/flt32 one.
- riscv and csky uses the generic template implementation that
does not provide SVID support. For both cases a new exp10f
version is not added, but rather the symbols version of the
generic sysdeps/ieee754/flt32 is adjusted instead.
Checked on aarch64-linux-gnu, x86_64-linux-gnu, i686-linux-gnu,
powerpc64le-linux-gnu.
This is part of the libpthread removal project:
<https://sourceware.org/ml/libc-alpha/2019-10/msg00080.html>
Use __getline instead of __getdelim to avoid a localplt failure.
Likewise for __getrlimit/getrlimit.
The abilist updates were performed by:
git ls-files 'sysdeps/unix/sysv/linux/**/libc.abilist' \
| while read x ; do
echo "GLIBC_2.32 pthread_getattr_np F" >> $x
done
python3 scripts/move-symbol-to-libc.py --only-linux pthread_getattr_np
The private export of __pthread_getaffinity_np is no longer needed, but
the hidden alias still necessary so that the symbol can be exported with
versioned_symbol.
Reviewed-by: Carlos O'Donell <carlos@redhat.com>
Tested-by: Carlos O'Donell <carlos@redhat.com>
This is part of the libpthread removal project:
<https://sourceware.org/ml/libc-alpha/2019-10/msg00080.html>
The abilist updates were performed by:
git ls-files 'sysdeps/unix/sysv/linux/**/libc.abilist' \
| while read x ; do
echo "GLIBC_2.32 pthread_getaffinity_np F" >> $x
done
python3 scripts/move-symbol-to-libc.py pthread_getaffinity_np
Reviewed-by: Carlos O'Donell <carlos@redhat.com>
Tested-by: Carlos O'Donell <carlos@redhat.com>
This is part of the libpthread removal project:
<https://sourceware.org/ml/libc-alpha/2019-10/msg00080.html>
The symbol did not previously exist in libc, so a new GLIBC_2.32
symbol is needed, to get correct dependency for binaries which
use the symbol but no longer link against libpthread.
The abilist updates were performed by:
git ls-files 'sysdeps/unix/sysv/linux/**/libc.abilist' \
| while read x ; do
echo "GLIBC_2.32 pthread_attr_setaffinity_np F" >> $x
done
python3 scripts/move-symbol-to-libc.py pthread_attr_setaffinity_np
Reviewed-by: Carlos O'Donell <carlos@redhat.com>
Tested-by: Carlos O'Donell <carlos@redhat.com>
Remove the sem-pad.h file and instead have architectures override the
struct semid_ds via the bits/types/struct_semid_ds.h file.
Reviewed-by: Adhemerval Zanella <adhemerval.zanella@linaro.org>
This is part of the libpthread removal project:
<https://sourceware.org/ml/libc-alpha/2019-10/msg00080.html>
A new symbol version is added on libc to force loading failure
instead of lazy binding one for newly binaries with old loaders.
Checked with a build against all affected ABIs.
Linux 5.6 has new openat2 and pidfd_getfd syscalls. This patch adds
them to syscall-names.list and regenerates the arch-syscall.h files.
Tested with build-many-glibcs.py.
This addresses an issue that is present mainly on SMP machines running
threaded code. In a typical indirect call or PLT import stub, the
target address is loaded first. Then the global pointer is loaded into
the PIC register in the delay slot of a branch to the target address.
During lazy binding, the target address is a trampoline which transfers
to _dl_runtime_resolve().
_dl_runtime_resolve() uses the relocation offset stored in the global
pointer and the linkage map stored in the trampoline to find the
relocation. Then, the function descriptor is updated.
In a multi-threaded application, it is possible for the global pointer
to be updated between the load of the target address and the global
pointer. When this happens, the relocation offset has been replaced
by the new global pointer. The function pointer has probably been
updated as well but there is no way to find the address of the function
descriptor and to transfer to the target. So, _dl_runtime_resolve()
typically crashes.
HP-UX addressed this problem by adding an extra pc-relative branch to
the trampoline. The descriptor is initially setup to point to the
branch. The branch then transfers to the trampoline. This allowed
the trampoline code to figure out which descriptor was being used
without any modification to user code. I didn't use this approach
as it is more complex and changes function pointer canonicalization.
The order of loading the target address and global pointer in
indirect calls was not consistent with the order used in import stubs.
In particular, $$dyncall and some inline versions of it loaded the
global pointer first. This was inconsistent with the global pointer
being updated first in dl-machine.h. Assuming the accesses are
ordered, we want elf_machine_fixup_plt() to store the global pointer
first and calls to load it last. Then, the global pointer will be
correct when the target function is entered.
However, just to make things more fun, HP added support for
out-of-order execution of accesses in PA 2.0. The accesses used by
calls are weakly ordered. So, it's possibly under some circumstances
that a function might be entered with the wrong global pointer.
However, HP uses weakly ordered accesses in 64-bit HP-UX, so I assume
that loading the global pointer in the delay slot of the branch must
work consistently.
The basic fix for the race is a combination of modifying user code to
preserve the address of the function descriptor in register %r22 and
setting the least-significant bit in the relocation offset. The
latter was suggested by Carlos as a way to distinguish relocation
offsets from global pointer values. Conventionally, %r22 is used
as the address of the function descriptor in calls to $$dyncall.
So, it wasn't hard to preserve the address in %r22.
I have updated gcc trunk and gcc-9 branch to not clobber %r22 in
$$dyncall and inline indirect calls. I have also modified the import
stubs in binutils trunk and the 2.33 branch to preserve %r22. This
required making the stubs one instruction longer but we save one
relocation. I also modified binutils to align the .plt section on
a 8-byte boundary. This allows descriptors to be updated atomically
with a floting-point store.
With these changes, _dl_runtime_resolve() can fallback to an alternate
mechanism to find the relocation offset when it has been clobbered.
There's just one additional instruction in the fast path. I tested
the fallback function, _dl_fix_reloc_arg(), by changing the branch to
always use the fallback. Old code still runs as it did before.
Fixes bug 23296.
Reviewed-by: Carlos O'Donell <carlos@redhat.com>
Writable, executable segments defeat security hardening. The
existing check for DT_TEXTREL does not catch this.
hppa and SPARC currently keep the PLT in an RWX load segment.
It is necessary to export __pthread_cond_init from libc because
the C11 condition variable needs it and is still left in libpthread.
This is part of the libpthread removal project:
<https://sourceware.org/ml/libc-alpha/2019-10/msg00080.html>
Reviewed-by: Adhemerval Zanella <adhemerval.zanella@linaro.org>
It is necessary to export __pthread_cond_destroy from libc because
the C11 condition variable needs it and is still left in libpthread.
This is part of the libpthread removal project:
<https://sourceware.org/ml/libc-alpha/2019-10/msg00080.html>
Reviewed-by: Adhemerval Zanella <adhemerval.zanella@linaro.org>
Exporting functions and relying on symbol interposition from libc.so
makes the choice of implementation dependent on DT_NEEDED order, which
is not what some compiler drivers expect.
This commit replaces one magic mechanism (symbol interposition) with
another one (preprocessor-/compiler-based redirection). This makes
the hand-over from the minimal malloc to the full malloc more
explicit.
Removing the ABI symbols is backwards-compatible because libc.so is
always in scope, and the dynamic loader will find the malloc-related
symbols there since commit f0b2132b35
("ld.so: Support moving versioned symbols between sonames
[BZ #24741]").
Reviewed-by: Carlos O'Donell <carlos@redhat.com>
With all Linux ABIs using the expected Linux kABI to indicate
syscalls errors, the INTERNAL_SYSCALL_DECL is an empty declaration
on all ports.
This patch removes the 'err' argument on INTERNAL_SYSCALL* macro
and remove the INTERNAL_SYSCALL_DECL usage.
Checked with a build against all affected ABIs.
With all Linux ABIs using the expected Linux kABI to indicate
syscalls errors, there is no need to replicate the INLINE_SYSCALL.
The generic Linux sysdep.h includes errno.h even for !__ASSEMBLER__,
which is ok now and it allows cleanup some archaic code that assume
otherwise.
Checked with a build against all affected ABIs.
Use <arch-syscall.h> instead of <asm/unistd.h> to obtain the system
call numbers. A few direct includes of <asm/unistd.h> need to be
removed (if the system call numbers are already provided indirectly
by <sysdep.h>) or replaced with <sys/syscall.h>.
Current Linux headers for alpha define the required system call names,
so most of the _NR_* hacks are no longer needed. For the 32-bit arm
architecture, eliminate the INTERNAL_SYSCALL_ARM macro, now that we
have regular system call names for cacheflush and set_tls. There are
more such cleanup opportunities for other architectures, but these
cleanups are required to avoid macro redefinition errors during the
build.
For ia64, it is desirable to use <asm/break.h> directly to obtain
the break number for system calls (which is not a system call number
itself). This requires replacing __BREAK_SYSCALL with
__IA64_BREAK_SYSCALL because the former is defined as an alias in
<asm/unistd.h>, but not in <asm/break.h>.
Reviewed-by: Siddhesh Poyarekar <siddhesh@sourceware.org>
The new tables are currently only used for consistency checks
with the installed kernel headers and the architecture-independent
system call names table. They are based on Linux 5.4.
The goal is to use these architecture-specific tables to ensure
that system call wrappers are available irrespective of the version
of the installed kernel headers.
The tables are formatted in the form of C header files so that they
can be used directly in an #include directive, without external
preprocessing. (External preprocessing of a plain table file
would introduce cross-subdirectory dependency issues.) However,
the intent is that they can still be treated as tables and can be
processed by simple tools.
The irregular system call names on 32-bit arm add a complication.
The <fixup-asm-unistd.h> header is introduced to work around that,
and the system calls are listed under regular names in the
<arch-syscall.h> file.
A make target, update-syscalls-list, is added to patch the glibc
sources with data from the current kernel headers.
Reviewed-by: Siddhesh Poyarekar <siddhesh@sourceware.org>
