Also move sysdeps/i386/fpu/s_fpclassifyl.c to
sysdeps/x86/fpu/s_fpclassifyl.c and remove
sysdeps/x86_64/fpu/s_fpclassifyl.c
Reviewed-by: Adhemerval Zanella <adhemerval.zanella@linaro.org>
Add Intel Linear Address Masking (LAM) support to <sys/platform/x86.h>.
HAS_CPU_FEATURE (LAM) can be used to detect if LAM is enabled in CPU.
LAM modifies the checking that is applied to 64-bit linear addresses,
allowing software to use of the untranslated address bits for metadata.
Add various defines and stubs for enabling MTE on AArch64 sysv-like
systems such as Linux. The HWCAP feature bit is copied over in the
same way as other feature bits. Similarly we add a new wrapper header
for mman.h to define the PROT_MTE flag that can be used with mmap and
related functions.
We add a new field to struct cpu_features that can be used, for
example, to check whether or not certain ifunc'd routines should be
bound to MTE-safe versions.
Finally, if we detect that MTE should be enabled (ie via the glibc
tunable); we enable MTE during startup as required.
Support in the Linux kernel was added in version 5.10.
Reviewed-by: Szabolcs Nagy <szabolcs.nagy@arm.com>
Older versions of the Linux kernel headers obviously lack support for
memory tagging, but we still want to be able to build in support when
using those (obviously it can't be enabled on such systems).
The linux kernel extensions are made to the platform-independent
header (linux/prctl.h), so this patch takes a similar approach.
This patch adds the basic support for memory tagging.
Various flavours are supported, particularly being able to turn on
tagged memory at run-time: this allows the same code to be used on
systems where memory tagging support is not present without neededing
a separate build of glibc. Also, depending on whether the kernel
supports it, the code will use mmap for the default arena if morecore
does not, or cannot support tagged memory (on AArch64 it is not
available).
All the hooks use function pointers to allow this to work without
needing ifuncs.
Reviewed-by: DJ Delorie <dj@redhat.com>
This is clever, but it confuses downstream detection in at least zstd
and GNOME's glib. zstd has preprocessor tests for the 'st_mtime' macro,
which is not provided by the path using the anonymous union; glib checks
for the presence of 'st_mtimensec' in struct stat but then tries to
access that field in struct statx (which might be a bug on its own).
Checked with a build for alpha-linux-gnu.
setjmp() uses C code to store current registers into jmp_buf
environment. -fstack-protector-all places canary into setjmp()
prologue and clobbers 'a5' before it gets saved.
The change inhibits stack canary injection to avoid clobber.
When SA_SIGINFO is available, sysdeps/posix/s?profil.c use it, so we have to
fix the __profil_counter function accordingly, using sigcontextinfo.h's
sigcontext_get_pc.
SA_SIGINFO is actually just another way of expressing what we were
already passing over with struct sigcontext. This just introduces the
SIGINFO interface and fixes the posix values when that interface is
requested by the application.
asin and acos have slow paths for rounding the last bit that cause some
calls to be 500-1500x slower than average calls.
These slow paths are rare, a test of a trillion (1.000.000.000.000)
random inputs between -1 and 1 showed 32870 slow calls for acos and 4473
for asin, with most occurrences between -1.0 .. -0.9 and 0.9 .. 1.0.
The slow paths claim correct rounding and use __sin32() and __cos32()
(which compare two result candidates and return the closest one) as the
final step, with the second result candidate (res1) having a small offset
applied from res. This suggests that res and res1 are intended to be 1
ULP apart (which makes sense for rounding), barring bugs, allowing us to
pick either one and still remain within 1 ULP of the exact result.
Remove the slow paths as the accuracy is better than 1 ULP even without
them, which is enough for glibc.
Also remove code comments claiming correctly rounded results.
After slow path removal, checking the accuracy of 14.400.000.000 random
asin() and acos() inputs showed only three incorrectly rounded
(error > 0.5 ULP) results:
- asin(-0x1.ee2b43286db75p-1) (0.500002 ULP, same as before)
- asin(-0x1.f692ba202abcp-4) (0.500003 ULP, same as before)
- asin(-0x1.9915e876fc062p-1) (0.50000000001 ULP, previously exact)
The first two had the same error even before this commit, and they did
not use the slow path at all.
Checking 4934 known randomly found previously-slow-path asin inputs
shows 25 calls with incorrectly rounded results, with a maximum error of
0.500000002 ULP (for 0x1.fcd5742999ab8p-1). The previous slow-path code
rounded all these inputs correctly (error < 0.5 ULP).
The observed average speed increase was 130x.
Checking 36240 known randomly found previously-slow-path acos inputs
shows 42 calls with incorrectly rounded results, with a maximum error of
0.500000008 ULP (for 0x1.f63845056f35ep-1). The previous "exact"
slow-path code showed 34 calls with incorrectly rounded results, with the
same maximum error of 0.500000008 ULP (for 0x1.f63845056f35ep-1).
The observed average speed increase was 130x.
The functions could likely be trimmed more while keeping acceptable
accuracy, but this at least gets rid of the egregiously slow cases.
Tested on x86_64.
This patch updates the kernel version in the test tst-mman-consts.py
to 5.10. (There are no new MAP_* constants covered by this test in
5.10 that need any other header changes.)
Tested with build-many-glibcs.py.
GCC 6.5 fails to correctly build ldconfig with recent ld.so.cache
commits, e.g.:
785969a047
elf: Implement a string table for ldconfig, with tail merging
If glibc is build with gcc 6.5.0:
__builtin_add_overflow is used in
<glibc>/elf/stringtable.c:stringtable_finalize()
which leads to ldconfig failing with "String table is too large".
This is also recognizable in following tests:
FAIL: elf/tst-glibc-hwcaps-cache
FAIL: elf/tst-glibc-hwcaps-prepend-cache
FAIL: elf/tst-ldconfig-X
FAIL: elf/tst-ldconfig-bad-aux-cache
FAIL: elf/tst-ldconfig-ld_so_conf-update
FAIL: elf/tst-stringtable
See gcc "Bug 98269 - gcc 6.5.0 __builtin_add_overflow() with small
uint32_t values incorrectly detects overflow"
(https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98269)
Change sbrk to fail for !__libc_initial (in the generic
implementation). As a result, sbrk is (relatively) safe to use
for the __libc_initial case (from the main libc). It is therefore
no longer necessary to avoid using it in that case (or updating the
brk cache), and the __libc_initial flag does not need to be updated
as part of dlmopen or static dlopen.
As before, direct brk system calls on Linux may lead to memory
corruption.
Reviewed-by: Adhemerval Zanella <adhemerval.zanella@linaro.org>
Linux 5.10 has one new syscall, process_madvise. 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 symbol is not in the implementation reserved namespace for static
linking and it was never used: it seems it was mistakenly added in the
orignal strlen_asimd commit 436e4d5b96
Since we can't tell if the tunable value is set by user or not:
https://sourceware.org/bugzilla/show_bug.cgi?id=27069
remove the default REP MOVSB threshold tunable value so that the correct
default value will be set correctly by init_cacheinfo ().
Reviewed-by: Carlos O'Donell <carlos@redhat.com>
Re-mmap executable segments if possible instead of using mprotect
to add PROT_BTI. This allows using BTI protection with security
policies that prevent mprotect with PROT_EXEC.
If the fd of the ELF module is not available because it was kernel
mapped then mprotect is used and failures are ignored. To protect
the main executable even when mprotect is filtered the linux kernel
will have to be changed to add PROT_BTI to it.
The delayed failure reporting is mainly needed because currently
_dl_process_gnu_properties does not propagate failures such that
the required cleanups happen. Using the link_map_machine struct for
error propagation is not ideal, but this seemed to be the least
intrusive solution.
Fixes bug 26831.
Reviewed-by: Adhemerval Zanella <adhemerval.zanella@linaro.org>
To handle GNU property notes on aarch64 some segments need to
be mmaped again, so the fd of the loaded ELF module is needed.
When the fd is not available (kernel loaded modules), then -1
is passed.
The fd is passed to both _dl_process_pt_gnu_property and
_dl_process_pt_note for consistency. Target specific note
processing functions are updated accordingly.
Reviewed-by: Adhemerval Zanella <adhemerval.zanella@linaro.org>
Handle unaligned executable load segments (the bfd linker is not
expected to produce such binaries, but other linkers may).
Computing the mapping bounds follows _dl_map_object_from_fd more
closely now.
Fixes bug 26988.
Reviewed-by: Adhemerval Zanella <adhemerval.zanella@linaro.org>
The _dl_open_check and _rtld_main_check hooks are not called on the
dependencies of a loaded module, so BTI protection was missed on
every module other than the main executable and directly dlopened
libraries.
The fix just iterates over dependencies to enable BTI.
Fixes bug 26926.
It removes all the arch-specific assembly implementation. The
outliers are alpha, where its kernel ABI explict return -ENOMEM
in case of failure; and i686, where it can't use
"call *%gs:SYSINFO_OFFSET" during statup in static PIE.
Also some ABIs exports an additional ___brk_addr symbol and to
handle it an internal HAVE_INTERNAL_BRK_ADDR_SYMBOL is added.
Checked on x86_64-linux-gnu, i686-linux-gnu, adn with builsd for
the affected ABIs.
Reviewed-by: Tulio Magno Quites Machado Filho <tuliom@linux.ibm.com>
Subdirectories z13, z14, z15 can be selected, mostly based on the
level of support for vector instructions.
Co-Authored-By: Stefan Liebler <stli@linux.ibm.com>
float_t supposedly represents the type that is used to evaluate float
expressions internally. While the isa supports single-precision float
operations, the port of glibc to s390 incorrectly deferred to the
generic definitions which, back then, tied float_t to double. gcc by
default evaluates float in single precision, so that scenario violates
the C standard (sections 5.2.4.2.2 and 7.12 in C11/C17). With
-fexcess-precision=standard, gcc evaluates float in double precision,
which aligns with the standard yet at the cost of added conversion
instructions.
With this patch, we drop the s390-specific definition of float_t and
defer to the default behavior, which aligns float_t with the
compiler-defined FLT_EVAL_METHOD in a standard-compliant way.
Checked on s390x-linux-gnu with 31-bit and 64-bit builds.
The functions strtoimax, strtoumax, wcstoimax, wcstoumax currently
have three implementations each (wordsize-32, wordsize-64 and dummy
implementation in stdlib/ using #error), defining the functions as
thin wrappers round corresponding *_internal functions. Simplify the
code by changing them into aliases of functions such as strtol and
wcstoull. This is more consistent with how e.g. imaxdiv is handled.
Tested for x86_64 and x86.
This code manages the mappings of the available databases in NSS
(i.e. passwd, hosts, netgroup, etc) with the actions that should
be taken to do a query on those databases.
This is the main API between query functions scattered throughout
glibc and the underlying code (actions, modules, etc).
Reviewed-by: Siddhesh Poyarekar <siddhesh@sourceware.org>
Check HAS_CPU_FEATURE instead of CPU_FEATURE_USABLE for FSGSBASE, IBT,
LM, SHSTK and XSAVES since FSGSBASE requires kernel support, IBT/SHSTK/LM
require OS support and XSAVES is supervisor-mode only.
Following macros: lll_futex_timed_lock_pi, lll_futex_clock_wait_bitset,
lll_futex_wait_requeue_pi, lll_futex_timed_wait_requeue_pi are not
used anymore so are eligible for removal.
Build tests:
./src/scripts/build-many-glibcs.py glibcs
Reviewed-by: Adhemerval Zanella <adhemerval.zanella@linaro.org>
Reviewed-by: Alistair Francis <alistair.francis@wdc.com>
After gai_suspend and aio_suspend conversion to support 64 bit time and
hence rewriting the code to use only absolute variants of futex wait
functions (i.e. __futex_abstimed_wait64 and __futex_abstimed_wait_cancelable64)
futex_reltimed_wait{_cancelable} are not needed anymore and can be removed.
Build tests:
./src/scripts/build-many-glibcs.py glibcs
Reviewed-by: Adhemerval Zanella <adhemerval.zanella@linaro.org>
Reviewed-by: Alistair Francis <alistair.francis@wdc.com>
This change uses (in gai_misc.h):
- __futex_abstimed_wait64 (instead of futex_reltimed_wait)
- __futex_abstimed_wait_cancellable64
(instead of futex_reltimed_wait_cancellable)
from ./sysdeps/nptl/futex-helpers.h
The gai_suspend() accepts relative timeout, which then is converted to
absolute one.
The i686-gnu port (HURD) do not define DONT_NEED_GAI_MISC_COND and as it
doesn't (yet) support 64 bit time it uses not converted
pthread_cond_timedwait().
The __gai_suspend() is supposed to be run on ports with __TIMESIZE !=64 and
__WORDSIZE==32. It internally utilizes __gai_suspend_time64() and hence the
conversion from 32 bit struct timespec to 64 bit one is required.
For ports supporting 64 bit time the __gai_suspend_time64() will be used
either via alias (to __gai_suspend when __TIMESIZE==64) or redirection
(when -D_TIME_BITS=64 is passed).
Build tests:
./src/scripts/build-many-glibcs.py glibcs
Reviewed-by: Adhemerval Zanella <adhemerval.zanella@linaro.org>
Reviewed-by: Alistair Francis <alistair.francis@wdc.com>
Libraries from these subdirectories are added to the cache
with a special hwcap bit DL_CACHE_HWCAP_EXTENSION, so that
they are ignored by older dynamic loaders.
Reviewed-by: Adhemerval Zanella <adhemerval.zanella@linaro.org>
A previously unused new-format header field is used to record
the address of an extension directory.
This change adds a demo extension which records the version of
ldconfig which builds a file.
Reviewed-by: Adhemerval Zanella <adhemerval.zanella@linaro.org>
Use a reserved byte in the new format cache header to indicate whether
the file is in little endian or big endian format. Eventually, this
information could be used to provide a unified cache for qemu-user
and similiar scenarios.
Reviewed-by: Adhemerval Zanella <adhemerval.zanella@linaro.org>
This hacks non-power-set processing into _dl_important_hwcaps.
Once the legacy hwcaps handling goes away, the subdirectory
handling needs to be reworked, but it is premature to do this
while both approaches are still supported.
ld.so supports two new arguments, --glibc-hwcaps-prepend and
--glibc-hwcaps-mask. Each accepts a colon-separated list of
glibc-hwcaps subdirectory names. The prepend option adds additional
subdirectories that are searched first, in the specified order. The
mask option restricts the automatically selected subdirectories to
those listed in the option argument. For example, on systems where
/usr/lib64 is on the library search path,
--glibc-hwcaps-prepend=valgrind:debug causes the dynamic loader to
search the directories /usr/lib64/glibc-hwcaps/valgrind and
/usr/lib64/glibc-hwcaps/debug just before /usr/lib64 is searched.
Reviewed-by: Adhemerval Zanella <adhemerval.zanella@linaro.org>
The previous definition of THREAD_SELF did not tell the compiler
that %fs (or %gs) usage is invalid for the !DL_LOOKUP_GSCOPE_LOCK
case in _dl_lookup_symbol_x. As a result, ld.so could try to use the
TCB before it was initialized.
As the comment in tls.h explains, asm volatile is undesirable here.
Using the __seg_fs (or __seg_gs) namespace does not interfere with
optimization, and expresses that THREAD_SELF is potentially trapping.
This reverts commit 81b83ff61f to move
__xmknod{at} back to default symbols. ABIs with default symbol version
of 2.33 or newer (such as riscv32) continue to just provide the mknod*
symbols.
The idea is to not force static libraries built against old glibc
to update against new glibcs (since they reference the the
xmknod{at} symbols).
Checked on x86_64-linux-gnu and i686-linux-gnu.
This reverts commit 20b39d5946 to move
{f}xstat{at} back to default symbols. ABIs with default symbol version
of 2.33 or newer (such as riscv32) continue to just provide the stat
symbols.
The idea is to not force static libraries built against old glibc
to update against new glibcs (since they reference the old
{f}xstat{at} symbols).
Checked on x86_64-linux-gnu and i686-linux-gnu.
The earlier implementation of this, __lll_clocklock, calls lll_clockwait
that doesn't return the futex syscall error codes. It always tries again
if that fails.
However in the current implementation, when the futex returns EAGAIN,
__futex_clocklock64 will also return EGAIN, even if the futex is taken.
This patch fixes the EAGAIN issue and also adds a check for EINTR. As
futex syscall can return EINTR if the thread is interrupted by a signal.
In this case I'm assuming the function should continue trying to lock as
there is no mention to about it on POSIX. Also add a test for both
scenarios.
Reviewed-by: Adhemerval Zanella <adhemerval.zanella@linaro.org>
Programatically generate simple wrappers for interesting libm *f128
objects. Selected functions are transcendental functions or
those with trivial compiler builtins. This can result in a 2-3x
speedup (e.g logf128 and expf128).
A second set of implementation files are generated which include
the first implementation encountered along the search path. This
usually works, except when a wrapper is overriden and makefile
search order slightly diverges from include order. Likewise,
wrapper object files are created for each generated file. These
hold the ifunc selection routines which export ABI.
Next, several shared headers are intercepted to control renaming of
asm function redirects are used first, and sometimes macro renames
if the former is impractical.
Notably, if the request machine supports hardware IEEE128 (i.e POWER9
and newer) this ifunc machinery is disabled. Likewise existing
ifunc support for float128 is consolidated into this (e.g sqrtf128
and fmaf128).
Reviewed-by: Tulio Magno Quites Machado Filho <tuliom@linux.ibm.com>
The aio_suspend function has been converted to support 64 bit time.
This change uses (in aio_misc.h):
- __futex_abstimed_wait64 (instead of futex_reltimed_wait)
- __futex_abstimed_wait_cancellable64
(instead of futex_reltimed_wait_cancellable)
from ./sysdeps/nptl/futex-helpers.h
The aio_suspend() accepts relative timeout, which then is converted to
absolute one.
The i686-gnu port (HURD) do not define DONT_NEED_AIO_MISC_COND and as it
doesn't (yet) support 64 bit time it uses not converted
pthread_cond_timedwait().
The __aio_suspend() is supposed to be run on ports with __TIMESIZE !=64 and
__WORDSIZE==32. It internally utilizes __aio_suspend_time64() and hence the
conversion from 32 bit struct timespec to 64 bit one is required.
For ports supporting 64 bit time the __aio_suspend_time64() will be used
either via alias (to __aio_suspend when __TIMESIZE==64) or redirection
(when -D_TIME_BITS=64 is passed).
Build tests:
./src/scripts/build-many-glibcs.py glibcs
Reviewed-by: Alistair Francis <alistair.francis@wdc.com>
Reviewed-by: Adhemerval Zanella <adhemerval.zanella@linaro.org>
The 878fe624d4 changed lll_futex_timed_wait, which expects a relative
timeout, with a __futex_abstimed_wait64, which expects an absolute
timeout. However the code still passes a relative timeout.
Also, the PTHREAD_PRIO_PROTECT support for clocks different than
CLOCK_REALTIME was broken since the inclusion of
pthread_mutex_clocklock (9d20e22e46) since lll_futex_timed_wait
always use CLOCK_REALTIME.
This patch fixes by removing the relative time calculation. It
also adds some xtests that tests both thread and inter-process
usage.
Checked on x86_64-linux-gnu.
The commit 605f38177d (sh: Split BE/LE abilist) did not take in
consideration the SH4 fpu support.
Checked with a build for sh4-linux-gnu and manually checked that
the implementations at sysdeps/sh/sh4/fpu/ are selected.
John Paul Adrian Glaubitz also confirmed it fixes the build issues
he encontered.
The align the GNU extension with the others one that accept specify
which clock to wait for (such as pthread_mutex_clocklock).
Check on x86_64-linux-gnu.
Reviewed-by: Lukasz Majewski <lukma@denx.de>
Linux futex FUTEX_LOCK_PI operation only supports CLOCK_REALTIME,
so pthread_mutex_clocklock operation with priority aware mutexes
may fail depending of the input timeout.
Also, it is not possible to convert a CLOCK_MONOTONIC to a
CLOCK_REALTIME due the possible wall clock time change which might
invalid the requested timeout.
Checked on x86_64-linux-gnu and i686-linux-gnu.
Reviewed-by: Lukasz Majewski <lukma@denx.de>
For non null timeouts, the __futex_clocklock_wait64 creates an a
relative timeout by subtracting the current time from the input
argument. The same behavior can be obtained with FUTEX_WAIT_BITSET
without the need to calculate the relative timeout. Besides consolidate
the code it also avoid the possible relative timeout issues [1].
The __futex_abstimed_wait64 needs also to return EINVAL syscall
errors.
Checked on x86_64-linux-gnu and i686-linux-gnu.
[1] https://sourceware.org/pipermail/libc-alpha/2020-November/119881.html
Reviewed-by: Lukasz Majewski <lukma@denx.de>
And add a small optimization to avoid setting the operation for the
32-bit time fallback operation.
Checked on x86_64-linux-gnu and i686-linux-gnu.
Reviewed-by: Lukasz Majewski <lukma@denx.de>
It can be replaced with a __futex_abstimed_wait_cancelable64 call,
with the advantage that there is no need to further clock adjustments
to create a absolute timeout. It allows to remove the now ununsed
futex_timed_wait_cancel64 internal function.
Checked on x86_64-linux-gnu and i686-linux-gnu.
Reviewed-by: Lukasz Majewski <lukma@denx.de>
It is used solely on __pthread_cond_wait_common and the call can be
replaced by a __futex_abstimed_wait_cancelable64 one.
Checked on x86_64-linux-gnu and i686-linux-gnu.
Reviewed-by: Lukasz Majewski <lukma@denx.de>
The __futex_abstimed_wait usage was remove with 3102e28bd1 and the
__futex_abstimed_wait_cancelable by 323592fdc9 and b8d3e8fbaa.
The futex_lock_pi can be replaced by a futex_lock_pi64.
Checked on x86_64-linux-gnu and i686-linux-gnu.
Reviewed-by: Lukasz Majewski <lukma@denx.de>
PT_THREAD_POINTER is currenty defined inside a #ifndef __ASSEMBLER__ block, but
its usage should not be limited to C code, as it can be useful when accessing
the TLS from assembly code as well.
Reviewed-by: Tulio Magno Quites Machado Filho <tuliom@linux.ibm.com>
On GNU/Hurd we not only need $(common-objpfx) in LD_LIBRARY_PATH when loading
dynamic objects, but also $(common-objpfx)/mach and $(common-objpfx)/hurd. This
adds an ld-library-path variable to be used as LD_LIBRARY_PATH basis in
Makefiles, and a sysdep-ld-library-path variable for sysdeps to add some
more paths, here mach/ and hurd/.
Now __thread_gscope_wait (the function behind THREAD_GSCOPE_WAIT,
formerly __wait_lookup_done) can be implemented directly in ld.so,
eliminating the unprotected GL (dl_wait_lookup_done) function
pointer.
Reviewed-by: Adhemerval Zanella <adhemerval.zanella@linaro.org>
On ports with __TIMESIZE != 64 the remaining time argument always receives
pointer to struct __timespec64 instance. This is the different behavior
when compared to 64 bit versions of clock_nanosleep and nanosleep
functions, which receive NULL.
To avoid any potential issues, we also pass NULL when *rem pointer is
NULL.
Reported-by: Andreas Schwab <schwab@suse.de>
Reviewed-by: Alistair Francis <alistair.francis@wdc.com>
The thrd_sleep function has been converted to support 64 bit time.
It was also necessary to provide Linux specific copy of it to avoid
problems on i686-gnu (i.e. HURD) port, which is not providing
clock_nanosleep() supporting 64 bit time.
The thrd_sleep is a wrapper on POSIX threads to provide C11 standard
threads interface. It directly calls __clock_nanosleep64().
Build tests:
./src/scripts/build-many-glibcs.py glibcs
Reviewed-by: Alistair Francis <alistair.francis@wdc.com>
The mtx_timedlock function has been converted to support 64 bit time.
It was also necessary to provide Linux specific copy of it to avoid
problems on i686-gnu (i.e. HURD) port, which is not providing
pthread_mutex_timedlock() supporting 64 bit time.
The mtx_timedlock is a wrapper on POSIX threads to provide C11 standard
threads interface. It directly calls __pthread_mutex_timedlock64().
Build tests:
./src/scripts/build-many-glibcs.py glibcs
Reviewed-by: Alistair Francis <alistair.francis@wdc.com>
The cnd_timedwait function has been converted to support 64 bit time.
It was also necessary to provide Linux specific copy of it to avoid
problems on i686-gnu (i.e. HURD) port, which is not providing
pthread_cond_timedwait() supporting 64 bit time.
Moreover, a linux specific copy of thrd_priv.h header file has been
added as well.
The cnd_timedwait is a wrapper on POSIX threads to provide C11 standard
threads interface. It directly calls __pthread_cond_timedwait64().
Build tests:
./src/scripts/build-many-glibcs.py glibcs
Reviewed-by: Alistair Francis <alistair.francis@wdc.com>
See
https://sourceware.org/pipermail/libc-alpha/2020-November/119575.html
lib{mach,hurd}user.so gets relocated before libc.so, but its references
to strpcpy and memcpy would need an ifunc decision, which e.g. on
x86 relies on cpu_features, but libc.so's _rtld_global_ro is not
relocated yet.
We can however just make lib{mach,hurd}user.so only call non-ifunc
functions, which can be relocated before libc.so is relocated.
The tls.h inclusion is not really required and limits possible
definition on more arch specific headers.
This is a cleanup to allow inline functions on sysdep.h, more
specifically on i386 and ia64 which requires to access some tls
definitions its own.
No semantic changes expected, checked with a build against all
affected ABIs.
Most systems are SMP, so optimizing for the UP case is no longer
approriate. A dynamic check based on the kernel identification
has been only implemented for i386 anyway.
To disable adaptive mutexes on sh, define DEFAULT_ADAPTIVE_COUNT
as zero for this architecture.
Reviewed-by: Adhemerval Zanella <adhemerval.zanella@linaro.org>
The UP macro is never defined. Also define LOCK_PREFIX
unconditionally, to the same string.
Reviewed-by: Adhemerval Zanella <adhemerval.zanella@linaro.org>
Now that _hurd_libc_proc_init is idempotent, we can always call it,
independently of the __libc_multiple_libcs test which may not match
whether signals should be started or not.
Add stpncpy support into the POWER9 strncpy.
Reviewed-by: Matheus Castanho <msc@linux.ibm.com>
Reviewed-by: Tulio Magno Quites Machado Filho <tuliom@linux.ibm.com>
Similar to the strcpy P9 optimization, this version uses VSX to improve
performance.
Reviewed-by: Matheus Castanho <msc@linux.ibm.com>
Reviewed-by: Tulio Magno Quites Machado Filho <tuliom@linux.ibm.com>
Notifying the proc server is an involved task, and unleashes various signal
handling etc. so we have to do this after e.g. ifunc relocations are
completed.
Since htl does not actually need a stack switch, we can initialize it
like nptl is, avoiding all sorts of startup issues with ifunc.
More precisely, htl defines __pthread_initialize_minimal instead of the
elder _cthread_init_routine. We can then drop the stack switching dances.
__attribute__((__aligned__)) selects an alignment that depends on
the micro-architecture selected by GCC flags. Enabling vector
extensions may increase the allignment. This is a problem when
building glibc as a collection of ELF multilibs with different
GCC flags because ld.so and libc.so/libpthread.so/&c may end up
with a different layout of struct pthread because of the
changing offset of its struct _Unwind_Exception field.
Tested-By: Matheus Castanho <msc@linux.ibm.com>
We need NO_RTLD_HIDDEN because of the need for PLT calls in ld.so.
See Roland's comment in
https://sourceware.org/bugzilla/show_bug.cgi?id=15605
"in the Hurd it's crucial that calls like __mmap be the libc ones
instead of the rtld-local ones after the bootstrap phase, when the
dynamic linker is being used for dlopen and the like."
We used to just avoid all hidden use in the rtld ; this commit switches to
keeping only those that should use PLT calls, i.e. essentially those defined in
sysdeps/mach/hurd/dl-sysdep.c:
__assert_fail
__assert_perror_fail
__*stat64
_exit
This fixes a few startup issues, notably the call to __tunable_get_val that is
made before PLTs are set up.
DL_SYSDEP_INIT and DL_PLATFORM_INIT were not getting called, leading to
missing x86 platform tuning, now mandatory with 0f09154c64
("x86: Initialize CPU info via IFUNC relocation [BZ 26203]")
Add support to query cache information on RISC-V through sysconf()
function. The cache information had been added in AUX vector of RISC-V
architecture in Linux kernel v.5.10-rc1.
Reviewed-by: Palmer Dabbelt <palmerdabbelt@google.com>
Acked-by: Palmer Dabbelt <palmerdabbelt@google.com>
This is required for the debugglibc.sh script to work. Tested by
successfully using this patched script, and a riscv64-linux testsuite
run.
We could perhaps call RTLD_EPILOGUE for ENTRY_POINT before calling
RTLD_PROLOGUE for _dl_start_user, but I don't think it matters.
OK?
Jim
The adjtime interface allows return the amount of time remaining
from any previous adjustment that has not yet been completed by
passing a NULL as first argument. This was introduced with y2038
support 0308077e3a.
Checked on i686-linux-gnu.
Reviewed-by: Lukasz Majewski <lukma@denx.de>
* sysdeps/unix/bsd/getpt.c (__getpt): Add oflag parameter, pass
it to the _open call and rename to...
(__bsd_openpt): ... new function.
(__getpt): Reimplement on top of __bsd_openpt.
(__posix_openpt): Replace stub with implementation on top of __bsd_openpt.
(posix_openpt): Remove stub warning.
The #include <sys/msg.h> is redundant as we do not use message specific
types for issuing syscalls to handle msg and shm. Only msgctl requires
this header.
Build tests:
./src/scripts/build-many-glibcs.py glibcs
This test fails without bug 26798 fixed because some integer registers
likely get clobbered by lazy binding and variant PCS only allows x16
and x17 to be clobbered at call time.
The test requires binutils 2.32.1 or newer for handling variant PCS
symbols. SVE registers are not covered by this test, to avoid the
complexity of handling multiple compile- and runtime feature support
cases.
The variant PCS support was ineffective because in the common case
linkmap->l_mach.plt == 0 but then the symbol table flags were ignored
and normal lazy binding was used instead of resolving the relocs early.
(This was a misunderstanding about how GOT[1] is setup by the linker.)
In practice this mainly affects SVE calls when the vector length is
more than 128 bits, then the top bits of the argument registers get
clobbered during lazy binding.
Fixes bug 26798.
GCC 11 introduces a -Wstringop-overflow warning for calls to functions
with an array argument passed as a pointer to memory not large enough
for that array. This includes the __sigsetjmp calls from
pthread_cleanup_push macros, because those use a structure in
__pthread_unwind_buf_t, which has a common initial subsequence with
jmp_buf but does not include the saved signal mask; this is OK in this
case because the second argument to __sigsetjmp is 0 so the signal
mask is not accessed.
To avoid this warning, use a function alias __sigsetjmp_cancel with
first argument an array of exactly the type used in the calls to the
function, if using GCC 11 or later. With older compilers, continue to
use __sigsetjmp with a cast, to avoid any issues with compilers
predating the returns_twice attribute not applying the same special
handling to __sigsetjmp_cancel as to __sigsetjmp.
Tested with build-many-glibcs.py for arm-linux-gnueabi that this fixes
the testsuite build failures.
struct file_entry_new starts with the fields of struct file_entry,
so the code can be shared if the size computation is made dynamic.
Reviewed-by: Adhemerval Zanella <adhemerval.zanella@linaro.org>
Modifying the shareable cache '__x86_shared_cache_size', which is a
factor in computing the non-temporal threshold parameter
'__x86_shared_non_temporal_threshold' to optimize memcpy for AMD Zen
architectures.
In the existing implementation, the shareable cache is computed as 'L3
per thread, L2 per core'. Recomputing this shareable cache as 'L3 per
CCX(Core-Complex)' has brought in performance gains.
As per the large bench variant results, this patch also addresses the
regression problem on AMD Zen architectures.
Reviewed-by: Premachandra Mallappa <premachandra.mallappa@amd.com>
It does not provide __clock_gettime64, the ftime y2038 support is
moved to a Linux specific implementation.
Checked with a build for i686-linux-gnu and on x86_64-linux and
i686-linux-gnu.
This patch updates the kernel version in the test tst-mman-consts.py
to 5.9. (There are no new MAP_* constants covered by this test in 5.9
that need any other header changes.)
Tested with build-many-glibcs.py.
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.
The commit:
"y2038: nptl: Convert pthread_mutex_{clock|timed}lock to support 64 bit"
SHA1: 29e9874a04
introduced support for 64 bit timeouts. Unfortunately, it was missing the
code for bitset - i.e. lll_futex_clock_wait_bitset C preprocessor macro
was used. As a result the 64 bit struct __timespec64 was coerced to 32
bit struct timespec and regression visible as timeout was observed
(nptl/tst-robust10 on s390).
Reported-by: Stefan Liebler <stli@linux.ibm.com>
Tested-by: Stefan Liebler <stli@linux.ibm.com>
__CSKY_HARD_FLOAT_ABI__ was added on gcc 11 to specify whether
-mfloat-abi=hard is set. On older gcc, the float ABI is defined
solely with __CSKY_HARD_FLOAT__. If __CSKY_HARD_FLOAT__ is set, it can
be either a hard-float ABI (gcc older than 11, or gcc11 -mfloat-abi=hard
(__CSKY_HARD_FLOAT_ABI__ is set) or -mfloat-abi=softfp
(__CSKY_HARD_FLOAT_ABI__ is not set). To be compatible with older gcc,
use __CSKY_HARD_FLOAT_FPU_SF__ identify if -mfloat-abi is supported,
because it is added to gcc at the same time as -mfloat-abi.
Reviewed-by: Mao Han <han_mao@linux.alibaba.com>
Reviewed-by: Adhemerval Zanella <adhemerval.zanella@linaro.org>
I couldn't pinpoint which standard has added it, but no other POSIX
system supports it and/or no longer provide it. The 'struct vtimes'
also has a lot of drawbacks due its limited internal type size.
I couldn't also see find any project that actually uses this symbol,
either in some dignostic way (such as sanitizer). So I think it should
be safer to just move to compat symbol, instead of deprecated. The
idea it to avoid new ports to export such broken interface (riscv32
for instance).
Checked on x86_64-linux-gnu and i686-linux-gnu.
In the glibc the time function can use vDSO (on power and x86 the
USE_IFUNC_TIME is defined), time syscall or 'default' time() from
./time/time.c (as a fallback).
In this patch the last function (time) has been refactored and moved
to ./sysdeps/unix/sysv/linux/time.c to be Linux specific.
The new __time64 explicit 64 bit function for providing 64 bit value of
seconds after epoch (by internally calling __clock_gettime64) has been
introduced.
Moreover, a 32 bit version - __time has been refactored to internally
use __time64.
The __time is now supposed to be used on systems still supporting 32 bit
time (__TIMESIZE != 64) - hence the necessary check for time_t potential
overflow.
The iFUNC vDSO direct call optimization has been removed from both i686 and
powerpc32 (USE_IFUNC_TIME is not defined for those architectures
anymore). The Linux kernel does not provide a y2038 safe implementation of
time neither it plans to provide it in the future, __clock_gettime64
should be used instead. Keeping support for this optimization would require
to handle another build permutation (!__ASSUME_TIME64_SYSCALLS &&
USE_IFUNC_TIME which adds more complexity and has limited use (since the
idea is to eventually have a y2038 safe glibc build).
Build tests:
./src/scripts/build-many-glibcs.py glibcs
Run-time tests:
- Run specific tests on ARM/x86 32bit systems (qemu):
https://github.com/lmajewski/meta-y2038 and run tests:
https://github.com/lmajewski/y2038-tests/commits/master
Above tests were performed with Y2038 redirection applied as well as
without to test proper usage of both __time64 and __time.
Reviewed-by: Adhemerval Zanella <adhemerval.zanella@linaro.org>
The dynamic linker should be chosen according to float abi, the
predefined macro __CSKY_HARD_FLOAT__ stand for architecure not
abi.
Reviewed-by: Mao Han <han_mao@linux.alibaba.com>
X86 CPU features in ld.so are initialized by init_cpu_features, which is
invoked by DL_PLATFORM_INIT from _dl_sysdep_start. But when ld.so is
loaded by static executable, DL_PLATFORM_INIT is never called. Also
x86 cache info in libc.o and libc.a is initialized by a constructor
which may be called too late. Since some fields in _rtld_global_ro
in ld.so are initialized by dynamic relocation, we can also initialize
x86 CPU features in _rtld_global_ro in ld.so and cache info in libc.so
by initializing dummy function pointers in ld.so and libc.so via IFUNC
relocation.
Key points:
1. IFUNC is always supported, independent of --enable-multi-arch or
--disable-multi-arch. Linker generates IFUNC relocations from input
IFUNC objects and ld.so performs IFUNC relocations.
2. There are no IFUNC dependencies in ld.so before dynamic relocation
have been performed,
3. The x86 CPU features in ld.so is initialized by DL_PLATFORM_INIT
in dynamic executable and by IFUNC relocation in dlopen in static
executable.
4. The x86 cache info in libc.o is initialized by IFUNC relocation.
5. In libc.a, both x86 CPU features and cache info are initialized from
ARCH_INIT_CPU_FEATURES, not by IFUNC relocation, before __libc_early_init
is called.
Note: _dl_x86_init_cpu_features can be called more than once from
DL_PLATFORM_INIT and during relocation in ld.so.
The fallback allocation is removed, so the possible size constraint
should be analyzed just once; __alloc_dir assumes that 'statp'
argument is non-null, and the max_buffer_size move to close its
used.
Checked on x86_64-linux-gnu and i686-linux-gnu.
This generic implementation already expects a getdents API which
is Linux specific. It also allows simplify it by assuming
_DIRENT_HAVE_D_RECLEN and _DIRENT_HAVE_D_OFF support.
The readdir are also expanded on each required implementation,
futher fixes and improvements will make parametrize the
implementation more complex.
Checked on x86_64-linux-gnu, i686-linux-gnu, and with a build
for all affected ABIs.
It basically calls the 64-bit time_t wait4 internal symbol.
Checked on x86_64-linux-gnu and i686-linux-gnu.
Reviewed-by: Lukasz Majewski <lukma@denx.de>
It was made deprecated on 2.31, so it moves to compat symbol after
two releases. It was also removed from exported symbol for riscv32
(since ABI will be supported on for 2.33).
Checked on x86_64-linux-gnu and i686-linux-gnu.
Reviewed-by: Lukasz Majewski <lukma@denx.de>
The generic implementation does not support time64 and the default
one return overflow for invalid tv_sec with UTIME_NOW / UTIME_OMIT
(which is valid since tv_sec in such cases is ignored by the
kernel).
Checked on x86_64-linux-gnu and i686-linux-gnu (on 5.4 and on 4.15
kernel).
Reviewed-by: Lukasz Majewski <lukma@denx.de>
Although not required by the standards, some code expects that a
successful stat call should not set errno. However since aa03f722f3
'linux: Add {f}stat{at} y2038 support', on 32-bit systems with 32-bit
time_t supporrt, stat implementation will first issues __NR_statx and
if it fails with ENOSYS issue the system stat syscall.
On architecture running on kernel without __NR_statx support the
first call will set the errno to ENOSYS, even when the following stat
syscall might not fail.
This patch fixes by using INTERNAL_SYSCALL and only setting the errno
value when function returns.
Checked on i686-linux-gnu, x86_64-linux-gnu, sparc64-linux-gnu,
sparcv9-linux-gnu, powerpc64-linux-gnu, powerpc64le-linux-gnu,
arm-linux-gnueabihf, and aarch64-linux-gnu.
The Linux shminfo fields are '__syscall_ulong_t' (which is 64-bit
for x32). This patch fixes the test to compare againt the correct
type and to only clamp the value if '__syscall_ulong_t' is the same
size of 'unsigned long int'.
Checked on x86_64-linux-gnu-x32.
Child of vfork should either call _exit or one of the exec family of
functions. But normally there is nothing to prevent child of vfork from
return of the vfork-calling function. Simpilfy x86 vfork when shadow
stack is in use to introduce mismatched shadow stack in child of vfork
to trigger SIGSEGV when the child returns from the function in which
vfork was called.
f_flags is added into struct statfs since Linux 2.6.36, which is lacked
in glibc's statfs64.c until now. So mount flags is uninitialized on
platforms having no statfs64 syscall in kernel, e.g., alpha and its derivation
The pthread_mutex_clocklock and pthread_mutex_timedlock have been converted
to support 64 bit time.
This change uses:
- New __futex_clocklock_wait64 (instead of lll_timedwait)
from ./sysdeps/nptl/futex-helpers.c and
- New __futex_clocklock64 function (instead of lll_clocklock)
- New futex_lock_pi64
defined in sysdeps/nptl/futex-internal.h
The pthread_mutex_{clock|timed}lock only accepts absolute time.
Moreover, there is no need to check for NULL passed as *abstime pointer to the
syscalls as those calls have exported symbols marked with __nonull attribute
for abstime.
Some architectures - namely x86, powerpc and s390 - do support lock elision.
For those - adjustments have been made in arch specific elision-*.c files
to use __futex_clocklock64 instead of lll_clocklock.
The __lll_lock_elision (aliased to __lll_clocklock_elision in e.g.
sysdeps/unix/sysv/linux/s390/elision-timed.c) just uses, in this patch
provided, __futex_clocklock64.
For systems with __TIMESIZE != 64 && __WORDSIZE == 32:
- Conversions between 64 bit time to 32 bit are necessary
- Redirection to pthread_mutex_{clock|timed}lock will provide support for 64
bit time
Build tests:
./src/scripts/build-many-glibcs.py glibcs
Reviewed-by: Adhemerval Zanella <adhemerval.zanella@linaro.org>
It avoids regressions on possible future commands that might require
additional libc support. The downside is new commands added by newer
kernels will need further glibc support.
Checked on x86_64-linux-gnu and i686-linux-gnu (Linux v4.15 and v5.4).
Both commands are Linux extensions where the third argument is either
a 'struct shminfo' (IPC_INFO) or a 'struct shm_info' (SHM_INFO) instead
of 'struct shmid_ds'. And their information does not contain any time
related fields, so there is no need to extra conversion for __IPC_TIME64.
The regression testcase checks for Linux specifix SysV ipc message
control extension. For SHM_INFO it tries to match the values against the
tunable /proc values and for MSG_STAT/MSG_STAT_ANY it check if the create\
shared memory is within the global list returned by the kernel.
Checked on x86_64-linux-gnu and on i686-linux-gnu (Linux v5.4 and on
Linux v4.15).
Add CPU detection of Neoverse N2 and Neoverse V1, and select __memcpy_simd as
the memcpy/memmove ifunc.
Reviewed-by: Adhemerval Zanella <adhemerval.zanella@linaro.org>
It adds the missing new symbols from 8ed005daf0 and 589260cef8 (which
added versioned symbols for {f,l}stat{at}{64} and mknod{a}t) on some
libc.abilist ABIs.
It also decouple mknod{at} from xmknod{at}. The riscv32 ABI was added
on 2.33, so it is safe to remove the old __xmknot{at} symbols and just
provide the newer mknod{at} ones.
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>
A new struct __stat{64}_t64 type is added with the required
__timespec64 time definition. Only LFS is added, 64-bit time with
32-bit offsets is not supposed to be supported (no existing glibc
configuration supports such a combination). It is done with an extra
__NR_statx call plus a conversion to the new __stat{64}_t64 type.
The statx call is done only for 32-bit time_t ABIs.
Internally some extra routines to copy from/to struct stat{64}
to struct __stat{64} used on multiple implementations (stat, fstat,
lstat, and fstatat) are added on a extra implementation
(stat_t64_cp.c). Alse some extra routines to copy from statx to
__stat{64} is added on statx_cp.c.
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>
They are no interna uses anymore. The riscv32 ABI was added on 2.33,
so it is safe to remove the old __{f,l}stat{at} symbols and just
provide the newer {f,l}stat{at} ones.
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 implements all the required syscall for the all Linux kABIS on
fstatat{64} instead of calling fxstatat{64}.
On non-LFS implementation, it handles 3 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.
2. Old KABIs with old non-LFS support (arm, i386, hppa, m68k,
microblaze, mips32, s390, sh, powerpc, and sparc32): it issues
__NR_fstatat64 and convert the result to struct stat.
3. 64-bit kABI outliers (mips64 and mips64-n32): it issues
__NR_newfstatat and convert the result to struct stat.
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.
1.2. 64-bit kABI outlier (alpha): it issues __NR_fstatat64.
1.3. 64-bit kABI outlier where struct stat64 does not match kernel
one (sparc64): it issues __NR_fstatat64 and convert the result
to struct stat64.
1.4. 32-bit kABI with default 64-bit time_t (arc, riscv32): it
issues __NR_statx and convert the result to struct stat64.
2. Old ABIs with XSTAT_IS_XSTAT64 being 0:
2.1. All kABIs with non-LFS support (arm, csky, i386, hppa, m68k,
microblaze, nios2, sh, powerpc32, and sparc32): it issues
__NR_fstatat64.
2.2. 64-bit kABI outliers (mips64 and mips64-n32): it issues
__NR_newfstatat and convert the result to struct stat64.
It allows to remove all the hidden definitions from the {f,l}xstat{64}
(some are still kept because Hurd requires it).
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>
Both fstatat and fstata64 calls the old fxstatat and fxstatat64
repectivelly with _STAT_VER, the one currently exported as default
for all ABIs.
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 common definitions are moved to a Linux generic stat.h while the
struct stat{64} definition are moved to a arch-specific struct_stat.h
header.
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 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>
It fixes the tst-cancelx{4,5} and tst-cancel24-{static} regression on
some platforms (arm and sparc32).
Checked on arm-linux-gnueabihf and sparcv9-linux-gnu.
The generic version is parallel to _dl_writev. It cannot use
_dl_writev directly because the errno value needs to be obtained
under a lock.
Reviewed-by: Adhemerval Zanella <adhemerval.zanella@linaro.org>
Current systems do not have BSD terminals, so the fallback code in
posix_openpt/getpt does not do anything. Also remove the file system
check for /dev/pts. Current systems always have a devpts file system
mounted there if /dev/ptmx exists.
grantpt is now essentially a no-op. It only verifies that the
argument is a ptmx-descriptor. Therefore, this change indirectly
addresses bug 24941.
Reviewed-by: Adhemerval Zanella <adhemerval.zanella@linaro.org>
The EINVAL error code is mandated by POSIX and documented in the
manual. Also clean up the unlockpt implementation a bit, assuming
that TIOCSPTLCK is always defined.
Enhance login/tst-grantpt to cover unlockpt corner cases.
Reviewed-by: Adhemerval Zanella <adhemerval.zanella@linaro.org>
GCC 11 -Warray-bounds triggers invalid warnings when building
Linux timer_create.c:
../sysdeps/unix/sysv/linux/timer_create.c: In function '__timer_create_new':
../sysdeps/unix/sysv/linux/timer_create.c:83:17: warning: array subscript 'struct timer[0]' is partly outside array bounds of 'unsigned char[8]' [-Warray-bounds]
83 | newp->sigev_notify = (evp != NULL
| ^~
../sysdeps/unix/sysv/linux/timer_create.c:59:47: note: referencing an object of size 8 allocated by 'malloc'
59 | struct timer *newp = (struct timer *) malloc (offsetof (struct timer,
| ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
60 | thrfunc));
| ~~~~~~~~~
The struct allocated for !SIGEV_THREAD timers only requires two 'int'
fields (sigev_notify and ktimerid) and the offsetof trick tries minimize
the memory usage by only allocation the required size. However,
although the resulting size is suffice for !SIGEV_THREAD time, accessing
the partially allocated object is error-prone and UB.
This patch fixes both issues by embedding the information whether
the timer if a SIGEV_THREAD in the returned 'timer_t'. For
!SIGEV_THREAD, the resulting 'timer_t' is the returned kernel timer
identifer (kernel_timer_t), while for SIGEV_THREAD it uses the fact
malloc returns at least _Alignof (max_align_t) pointers plus that
valid kernel_timer_t are always positive to set MSB bit of the returned
'timer_t' to indicate the timer handles a SIGEV_THREAD.
It allows to remove the memory allocation for !SIGEV_THREAD and also
remove the 'sigev_notify' field from 'struct timer'.
Checked on x86_64-linux-gnu and i686-linux-gnu.
This patch fixes part of bug 26647 (-Werror=array-parameter error
building with GCC 11 because of __sigsetjmp being declared using an
array parameter in one header and a pointer parameter in another).
The fix is to split the struct __jmp_buf_tag definition out to a
separate bits/types/ header so it can be included in pthread.h, so
that pthread.h can declare __sigsetjmp with the type contents visible,
so can use an array (as in setjmp.h) rather than a pointer in the
declaration.
Note that several other build failures with GCC 11 remain. This does
not fix the jmp_buf-related -Wstringop-overflow errors (also discussed
in bug 26647), or -Warray-parameter errors for other functions (bug
26686), or -Warray-bounds errors (bug 26687).
Tested, with older compilers, natively for x86_64 and with
build-many-glibc.py for aarch64-linux-gnu. Tested with
build-many-glibcs.py with GCC mainline for aarch64-linux-gnu that this
gets past the -Warray-parameter issue for __sigsetjmp (with the next
build failure being the other one discussed in bug 26647).
This is the helper function, which uses struct __timespec64
to provide 64 bit absolute time to futex syscalls.
The aim of this function is to move convoluted pre-processor
macro code from sysdeps/nptl/lowlevellock-futex.h to C
function in futex-internal.c
The futex_abstimed_wait64 function has been put into a separate
file on the purpose - to avoid issues apparent on the m68k
architecture related to small number of available registers (there
is not enough registers to put all necessary arguments in them if
the above function would be added to futex-internal.h with
__always_inline attribute).
Reviewed-by: Alistair Francis <alistair.francis@wdc.com>
It avoids regressions on possible future commands that might require
additional libc support. The downside is new commands added by newer
kernels will need further glibc support.
Checked on x86_64-linux-gnu and i686-linux-gnu (Linux v4.15 and v5.4).
Both commands are Linux extensions where the third argument is a
'struct msginfo' instead of 'struct msqid_ds' and its information
does not contain any time related fields (so there is no need to
extra conversion for __IPC_TIME64.
The regression testcase checks for Linux specifix SysV ipc message
control extension. For IPC_INFO/MSG_INFO it tries to match the values
against the tunable /proc values and for MSG_STAT/MSG_STAT_ANY it
check if the create message queue is within the global list returned
by the kernel.
Checked on x86_64-linux-gnu and on i686-linux-gnu (Linux v5.4 and on
Linux v4.15).
It avoids regressions on possible future commands that might require
additional libc support. The downside is new commands added by newer
kernels will need further glibc support.
Checked on x86_64-linux-gnu and i686-linux-gnu (Linux v4.15 and v5.4).
Handle SEM_STAT_ANY the same way as SEM_STAT so that the buffer argument
of SEM_STAT_ANY is properly passed to the kernel and back.
The regression testcase checks for Linux specifix SysV ipc message
control extension. For IPC_INFO/SEM_INFO it tries to match the values
against the tunable /proc values and for SEM_STAT/SEM_STAT_ANY it
check if the create message queue is within the global list returned
by the kernel.
Checked on x86_64-linux-gnu and on i686-linux-gnu (Linux v5.4 and on
Linux v4.15).
Co-authored-by: Adhemerval Zanella <adhemerval.zanella@linaro.org>
There are several compiler implementations that allow large stack
allocations to jump over the guard page at the end of the stack and
corrupt memory beyond that. See CVE-2017-1000364.
Compilers can emit code to probe the stack such that the guard page
cannot be skipped, but on aarch64 the probe interval is 64K by default
instead of the minimum supported page size (4K).
This patch enforces at least 64K guard on aarch64 unless the guard
is disabled by setting its size to 0. For backward compatibility
reasons the increased guard is not reported, so it is only observable
by exhausting the address space or parsing /proc/self/maps on linux.
On other targets the patch has no effect. If the stack probe interval
is larger than a page size on a target then ARCH_MIN_GUARD_SIZE can
be defined to get large enough stack guard on libc allocated stacks.
The patch does not affect threads with user allocated stacks.
Fixes bug 26691.
Both powerpc64 and s390x provides semtimedop through __NR_ipc for
pre v5.1 kernel. Neither the y2038 support (7c437d3778) nor the
attempt to fix an issue for !__ASSUME_DIRECT_SYSVIPC_SYSCALLS
(aaa12e9ff0) took this in consideration.
This patch fixes it by issuing __NR_semtimedop_time64 iff it is
defined, otherwise __NR_semtimeop is issued if both
__ASSUME_DIRECT_SYSVIPC_SYSCALLS it set and __NR_semtimedop is
define, other __NR_ipc is used instead. To summarize:
1. For 32-bit architetures __NR_semtimedop_time64 is always
issued. The fallback is used only for !__ASSUME_TIME64_SYSCALLS
and it issues either __NR_ipc or __NR_semtimedop.
2. For 64-bit architecture with wire-up SysV syscall
(__ASSUME_DIRECT_SYSVIPC_SYSCALLS and __NR_semtimeop defined)
__NR_semtimeop is issued.
3. Otherwise __NR_ipc is used instead.
Checked on x86_64-linux-gnu, i686-linux-gnu (kernel 4.15 and 5.4),
powerpc64le (kernel 4.18), and s390x (kernel 4.12).
Reviewed-by: Matheus Castanho <msc@linux.ibm.com>
This alias macro shall be moved to the beginning of the futex-internal.h
to be easily reused by other functions, which would support 64 bit time.
Reviewed-by: Alistair Francis <alistair.francis@wdc.com>
Reviewed-by: Adhemerval Zanella <adhemerval.zanella@linaro.org>
It returns the string of the error constant, not its description (as
strerrordesc_np). To handle the Hurd error mapping, the ERR_MAP was
removed from errlist.h to errlist.c.
Also, the testcase test-strerr (added on 325081b9eb) was not added
on the check build neither it builds correctly. This patch also
changed it to decouple from errlist.h, the expected return values
are added explicitly for both both strerrorname_np and strerrordesc_np
directly.
Checked on x86_64-linux-gnu and i686-linux-gnu. I also run a make
check for i686-gnu.
The __x86_shared_non_temporal_threshold determines when memcpy on x86
uses non_temporal stores to avoid pushing other data out of the last
level cache.
This patch proposes to revert the calculation change made by H.J. Lu's
patch of June 2, 2017.
H.J. Lu's patch selected a threshold suitable for a single thread
getting maximum performance. It was tuned using the single threaded
large memcpy micro benchmark on an 8 core processor. The last change
changes the threshold from using 3/4 of one thread's share of the
cache to using 3/4 of the entire cache of a multi-threaded system
before switching to non-temporal stores. Multi-threaded systems with
more than a few threads are server-class and typically have many
active threads. If one thread consumes 3/4 of the available cache for
all threads, it will cause other active threads to have data removed
from the cache. Two examples show the range of the effect. John
McCalpin's widely parallel Stream benchmark, which runs in parallel
and fetches data sequentially, saw a 20% slowdown with this patch on
an internal system test of 128 threads. This regression was discovered
when comparing OL8 performance to OL7. An example that compares
normal stores to non-temporal stores may be found at
https://vgatherps.github.io/2018-09-02-nontemporal/. A simple test
shows performance loss of 400 to 500% due to a failure to use
nontemporal stores. These performance losses are most likely to occur
when the system load is heaviest and good performance is critical.
The tunable x86_non_temporal_threshold can be used to override the
default for the knowledgable user who really wants maximum cache
allocation to a single thread in a multi-threaded system.
The manual entry for the tunable has been expanded to provide
more information about its purpose.
modified: sysdeps/x86/cacheinfo.c
modified: manual/tunables.texi
The wire-up syscall __NR_recvmmsg_time64 (for 32-bit) or
__NR_recvmmsg (for 64-bit) is used as default. The 32-bit fallback
is used iff __ASSUME_TIME64_SYSCALLS is not defined, which assumes the
kernel ABI provides either __NR_socketcall or __NR_recvmmsg
(32-bit time_t).
It does not handle the timestamps on ancillary data (SCM_TIMESTAMPING
records).
Checked on x86_64-linux-gnu and i686-linux-gnu.
Reviewed-by: Alistair Francis <alistair.francis@wdc.com>
It uses __clock_nanosleep64 and adds the __nanosleep64 symbol.
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>
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>
The syscall __NR_clock_getres_time64 (for 32-bit) or __NR_clock_getres
(for 64-bit) is used as default. The 32-bit fallback is used iff
__ASSUME_TIME64_SYSCALLS is not defined, which assumes the kernel ABI
provides either __NR_rt_sigtimedwait (32-bit time_t).
Since the symbol does not use any type which might be affected by the
time_t, there is no need to add a 64-bit variant.
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>
The syscall __NR_sigtimedwait_time64 (for 32-bit) or __NR_sigtimedwait
(for 64-bit) is used as default. The 32-bit fallback is used iff
__ASSUME_TIME64_SYSCALLS is not defined, which assumes the kernel ABI
provides either __NR_rt_sigtimedwait (32-bit time_t).
Checked on x86_64-linux-gnu and i686-linux-gnu.
Reviewed-by: Alistair Francis <alistair.francis@wdc.com>
The syscall __NR_pselect6_time64 (32-bit) or __NR_pselect6 (64-bit)
is used as default. For architectures with __ASSUME_TIME64_SYSCALLS
the 32-bit fallback uses __NR_select/__NR__newselect or __NR_pselect6
(it should cover the microblaze case where older kernels do not
provide __NR_pselect6).
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>
Similar to 64-bit time __futex_abstimed_wait_cancellable64, it should
check for overflow and convert to 32-bit timespec iff timeout is not
NULL.
It fixes some regression on i686-linux-gnu running on a 4.15 kernel.
dl_powerpc_cpu_features also needs to be protected by __GLRO to check
for the _rtld_global_ro realocation before accessing it.
Reviewed-by: Tulio Magno Quites Machado Filho <tuliom@linux.ibm.com>
The behavior of isnan/__builtin_isnan on bit patterns that do not
correspond to something that the CPU would produce from valid inputs
is currently under-defined in the toolchain. (The GCC built-in and
glibc disagree.)
The isnan check in PRINTF_FP_FETCH in stdio-common/printf_fp.c
assumes the GCC behavior that returns true for non-normal numbers
which are not specified as NaN. (The glibc implementation returns
false for such numbers.)
At present, passing non-normal numbers to __mpn_extract_long_double
causes this function to produce irregularly shaped multi-precision
integers, triggering undefined behavior in __printf_fp_l.
With GCC 10 and glibc 2.32, this behavior is not visible because
__builtin_isnan is used, which avoids calling
__mpn_extract_long_double in this case. This commit updates the
implementation of __mpn_extract_long_double so that regularly shaped
multi-precision integers are produced in this case, avoiding
undefined behavior in __printf_fp_l.
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>
This is similar to commit a26e2e9fea
"Allow memset local PLT reference for powerpc soft-float.".
GCC 10.1 results in the localplt test failing for RISC-V.
From the original commit for power-pc:
Since memset is documented as a function GCC may always implicitly
generate calls to, it seems reasonable to allow that local PLT
reference (just like those for libgcc functions that GCC implicitly
generates calls to and that are also exported from libc.so), which
this patch does.
Acked-by: Palmer Dabbelt <palmerdabbelt@google.com>
commit 04bba1e5d8
Author: H.J. Lu <hjl.tools@gmail.com>
Date: Wed Aug 5 13:51:56 2020 -0700
x86: Set CPU usable feature bits conservatively [BZ #26552]
Set CPU usable feature bits only for CPU features which are usable in
user space and whose usability can be detected from user space, excluding
features like FSGSBASE whose enable bit can only be checked in the kernel.
no longer turns on the usable bits of IBT and SHSTK since we don't know
if IBT and SHSTK are usable until much later. Use HAS_CPU_FEATURE to
check if the processor supports IBT and SHSTK.
Add Intel Key Locker:
https://software.intel.com/content/www/us/en/develop/download/intel-key-locker-specification.html
support to <sys/platform/x86.h>. Intel Key Locker has
1. KL: AES Key Locker instructions.
2. WIDE_KL: AES wide Key Locker instructions.
3. AESKLE: AES Key Locker instructions are enabled by OS.
Applications should use
if (CPU_FEATURE_USABLE (KL))
and
if (CPU_FEATURE_USABLE (WIDE_KL))
to check if AES Key Locker instructions and AES wide Key Locker
instructions are usable.
Install <sys/platform/x86.h> so that programmers can do
#if __has_include(<sys/platform/x86.h>)
#include <sys/platform/x86.h>
#endif
...
if (CPU_FEATURE_USABLE (SSE2))
...
if (CPU_FEATURE_USABLE (AVX2))
...
<sys/platform/x86.h> exports only:
enum
{
COMMON_CPUID_INDEX_1 = 0,
COMMON_CPUID_INDEX_7,
COMMON_CPUID_INDEX_80000001,
COMMON_CPUID_INDEX_D_ECX_1,
COMMON_CPUID_INDEX_80000007,
COMMON_CPUID_INDEX_80000008,
COMMON_CPUID_INDEX_7_ECX_1,
/* Keep the following line at the end. */
COMMON_CPUID_INDEX_MAX
};
struct cpuid_features
{
struct cpuid_registers cpuid;
struct cpuid_registers usable;
};
struct cpu_features
{
struct cpu_features_basic basic;
struct cpuid_features features[COMMON_CPUID_INDEX_MAX];
};
/* Get a pointer to the CPU features structure. */
extern const struct cpu_features *__x86_get_cpu_features
(unsigned int max) __attribute__ ((const));
Since all feature checks are done through macros, programs compiled with
a newer <sys/platform/x86.h> are compatible with the older glibc binaries
as long as the layout of struct cpu_features is identical. The features
array can be expanded with backward binary compatibility for both .o and
.so files. When COMMON_CPUID_INDEX_MAX is increased to support new
processor features, __x86_get_cpu_features in the older glibc binaries
returns NULL and HAS_CPU_FEATURE/CPU_FEATURE_USABLE return false on the
new processor feature. No new symbol version is neeeded.
Both CPU_FEATURE_USABLE and HAS_CPU_FEATURE are provided. HAS_CPU_FEATURE
can be used to identify processor features.
Note: Although GCC has __builtin_cpu_supports, it only supports a subset
of <sys/platform/x86.h> and it is equivalent to CPU_FEATURE_USABLE. It
doesn't support HAS_CPU_FEATURE.
The syscall __NR_pselect6_time64 (32-bit) or __NR_pselect6 (64-bit)
is used as default. For architectures with __ASSUME_TIME64_SYSCALLS
the 32-bit fallback uses __NR_pselec6.
To accomodate microblaze missing pselect6 support on kernel older
than 3.15 the fallback is moved to its own function to the microblaze
specific implementation can override it.
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>
Either the __NR_semtimedop_time64 (for 32-bit) or the __NR_semtimedop
(for 64-bit) syscall is used as default. The 32-bit fallback is used
iff __ASSUME_TIME64_SYSCALLS is not defined, which assumes the kernel
ABI provides either __NR_ipc or __NR_semtimeop (for 32-bit time_t).
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>
It avoid continuing issue the __NR_ppoll_time64 syscall once the kernel
advertise it does not support it.
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>
With arch-syscall.h it can now assumes the existance of either
__NR_clock_getres or __NR_clock_getres_time64. The 32-bit time_t
support is now only build for !__ASSUME_TIME64_SYSCALLS.
It also uses the time64-support functions to simplify it further.
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>
It replaces the internal usage of __{f,l}xstat{at}{64} with the
__{f,l}stat{at}{64}. It should not change the generate code since
sys/stat.h explicit defines redirections to internal calls back to
xstat* symbols.
Checked with a build for all affected ABIs. I also check on
x86_64-linux-gnu and i686-linux-gnu.
Reviewed-by: Lukasz Majewski <lukma@denx.de>
The __NR_mknodat syscall is supported on all kernels, so the generic
implementation is used as default.
Checked on x86_64-linux-gnu and i686-linux-gnu.
Reviewed-by: Lukasz Majewski <lukma@denx.de>
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>
Before this patch, the following tests were failing:
ppc and ppc64:
FAIL: math/test-ldouble-j0
ppc64le:
FAIL: math/test-float128-j0
FAIL: math/test-float64x-j0
FAIL: math/test-ibm128-j0
FAIL: math/test-ldouble-j0
- tst-mtx-recursive.c: mtx_init fails to use mtx_plain. Per C11
specs, using mtx_recursive alone is not supported. This isn't
catched because mtx_plain is defined as 0.
- tst-thrd-sleep.c: thrd_sleep returns 0 on success, a negative
value on failure. Testing against thrd_success is incorrect.
- tst-tss-basic.c: tss_set is incorrectly checkd for a non-0
value. The test should test aginst C11 threads error codes.
This isn't catched because thrd_success is defined as 0.
Note that all three tests fail on FreeBSD, which defines all mutex type
values, as well as all C11 threads error codes with non-0 values.
Set CPU usable feature bits only for CPU features which are usable in
user space and whose usability can be detected from user space, excluding
features like FSGSBASE whose enable bit can only be checked in the kernel.
Without this ULP patch these 3 tests fail on i686:
FAIL: math/test-float128-j0
FAIL: math/test-float64x-j0
FAIL: math/test-ldouble-j0
CPU info:
Vendor ID: GenuineIntel
CPU family: 6
Model: 85
Model name: Intel Xeon Processor (Cascadelake)
This is the first of a series of patches to sync with Gnulib commit
615b43e1f9. This patch adopts most of the changes of Gnulib, except it
retains GETCWD_RETURN_TYPE and does not always use a 64-bit internal
API. These remaining discrepancies will be addressed in later patches
in this series.
Checked on x86_64-linux-gnu and i686-linux-gnu.
A typo in commit 107e6a3c22 causes the
FMA4 code path to be taken on systems that support FMA, even if they do
not support FMA4. Fix this to detect FMA4.
The pthread_cond_clockwait and pthread_cond_timedwait have been converted
to support 64 bit time.
This change introduces new futex_abstimed_wait_cancelable64 function in
./sysdeps/nptl/futex-helpers.c, which uses futex_time64 where possible
and tries to replace low-level preprocessor macros from
lowlevellock-futex.h
The pthread_cond_{clock|timed}wait only accepts absolute time. Moreover,
there is no need to check for NULL passed as *abstime pointer as
__pthread_cond_wait_common() always passes non-NULL struct __timespec64
pointer to futex_abstimed_wait_cancellable64().
For systems with __TIMESIZE != 64 && __WORDSIZE == 32:
- Conversions between 64 bit time to 32 bit are necessary
- Redirection to __pthread_cond_{clock|timed}wait64 will provide support
for 64 bit time
The futex_abstimed_wait_cancelable64 function has been put into a separate
file on the purpose - to avoid issues apparent on the m68k architecture
related to small number of available registers (there is not enough
registers to put all necessary arguments in them if the above function
would be added to futex-internal.h with __always_inline attribute).
In fact - new function - namely __futex_abstimed_wait_cancellable32 is
used to reduce number of needed registers (as some in-register values are
stored on the stack when function call is made).
Build tests:
./src/scripts/build-many-glibcs.py glibcs
Run-time tests:
- Run specific tests on ARM/x86 32bit systems (qemu):
https://github.com/lmajewski/meta-y2038 and run tests:
https://github.com/lmajewski/y2038-tests/commits/master
Above tests were performed with Y2038 redirection applied as well as without
to test the proper usage of both __pthread_cond_{clock|timed}wait64 and
__pthread_cond_{clock|timed}wait.
Reviewed-by: Adhemerval Zanella <adhemerval.zanella@linaro.org>
X32 uses the same 64-bit syscall interface for set_thread_area. But
__NR_set_thread_area is missing from <asm/unistd_x32.h>. A kernel patch
was submitted:
From 7b05d5b43ae2545e0d4a3edb24205d18bc883626 Mon Sep 17 00:00:00 2001
From: "H.J. Lu" <hjl.tools@gmail.com>
Date: Sat, 15 Aug 2020 10:34:00 -0700
Subject: [PATCH] x86-64: Enable x32 set_thread_area
X32 uses the common 64-bit syscall interface for set_thread_area. Add
<fixup-asm-unistd.h> to provide __NR_set_thread_area.
Co-authored-by: Florian Weimer <fweimer@redhat.com>
On some microarchitectures performance of the backwards memmove improves if
the stores use STR with decreasing addresses. So change the memmove loop
in memcpy_advsimd.S to use 2x STR rather than STP.
Reviewed-by: Adhemerval Zanella <adhemerval.zanella@linaro.org>
This patch lays out the top-level organisation of the RISC-V 32-bit port.
It provides all the Implies files as well as various other fragments of
the build infrastructure.
Reviewed-by: Maciej W. Rozycki <macro@wdc.com>
Specify the minimum kernel version for RISC-V 32-bit as the 5.4 kernel.
We require this commit: "waitid: Add support for waiting for the current
process group" for the kernel as it adds support for the P_PGID id for
the waitid syscall. Without this patch we can't replace the wait4
syscall on 64-bit time_t only systems.
Reviewed-by: Maciej W. Rozycki <macro@wdc.com>
Conversions from a float to a long long on 32-bit RISC-V (RV32) may not
raise the correct exceptions on overflow, it also may raise spurious
"inexact" exceptions on non overflow cases. This patch fixes the
problem, similarly to the fix for MIPS, ARM and S390.
Reviewed-by: Maciej W. Rozycki <macro@wdc.com>
Add a libm-test-ulps for RV32, this is the same as the RV64 one.
This dosn't match what is generated by running `make regen-ulps` on RV32
QEMU, but the current in tree RV64 doesn't match that either.
Reviewed-by: Maciej W. Rozycki <macro@wdc.com>
This patch adds the ABI implementation for 32-bit RISC-V. It contains
the Linux-specific and RISC-V architecture code.
Reviewed-by: Maciej W. Rozycki <macro@wdc.com>
With RV32 support the list of possible RISC-V system directories
increases to:
- /lib64/lp64d
- /lib64/lp64
- /lib32/ilp32d
- /lib32/ilp32
- /lib (only ld.so)
This patch changes the add_system_dir () macro to support the new ilp32d
and ilp32 directories for RV32. While refactoring this code let's split
out the confusing if statements into a loop to make it easier to
understand and extend.
Reviewed-by: Maciej W. Rozycki <macro@wdc.com>
sysdep.h redefines only the syscall where the generic implementation
still does not have actual 64-bit time_t support:
/* Workarounds for generic code needing to handle 64-bit time_t. */
/* Fix sysdeps/unix/sysv/linux/clock_getcpuclockid.c. */
#define __NR_clock_getres __NR_clock_getres_time64
/* Fix sysdeps/nptl/lowlevellock-futex.h. */
#define __NR_futex __NR_futex_time64
[...]
This patch also adds a comment that it is a workaround to handle 64-bit
time_t and on each #define comment for which implementation it intends
to.
Reviewed-by: Maciej W. Rozycki <macro@wdc.com>
Remove a duplicate inclusion of <sysdeps/unix/sysdep.h> which is already
pulled via <sysdeps/unix/sysv/linux/generic/sysdep.h>, and the inclusion
of <errno.h> whose definition of `__set_errno' is not needed here.
Reviewed-by: Maciej W. Rozycki <macro@wdc.com>
Using the original glibc headers under bits/ let's make small
modifications to use 64-bit time_t and off_t for both RV32 and RV64.
For the typesizes.h, here are justifications for the changes from the
generic version (based on Arnd's very helpful feedback):
- All the !__USE_FILE_OFFSET64 types (__off_t, __ino_t, __rlim_t, ...)
are changed to match the 64-bit replacements.
- __time_t is defined to 64 bit, but no __time64_t is added. This makes
sense as we don't have the time64 support for other 32-bit
architectures yet, and it will be easy to change when that happens.
- __suseconds_t is 64-bit. This matches what we use the kernel ABI for
the few drivers that are relying on 'struct timeval' input arguments
in ioctl, as well as the adjtimex system call. It means that timeval
has to be defined without the padding, unlike timespec, which needs
padding.
Reviewed-by: Maciej W. Rozycki <macro@wdc.com>
With arch-syscall.h it can now assumes the existance of either
__NR_utimensat or __NR_utimensat_time64. The 32-bit time_t
support is now only build for !__ASSUME_TIME64_SYSCALLS.
Checked on x86_64-linux-gnu and i686-linux-gnu (on 5.4 and on 4.15
kernel).
Reviewed-by: Lukasz Majewski <lukma@denx.de>
With arch-syscall.h it can now assumes the existance of either
__NR_timer_settime or __NR_time_settime_time64. The 32-bit time_t
support is now only build for !__ASSUME_TIME64_SYSCALLS.
Checked on x86_64-linux-gnu and i686-linux-gnu (on 5.4 and on 4.15
kernel).
Reviewed-by: Lukasz Majewski <lukma@denx.de>
With arch-syscall.h it can now assumes the existance of either
__NR_timer_gettime or __NR_time_gettime_time64. The 32-bit time_t
support is now only build for !__ASSUME_TIME64_SYSCALLS.
Checked on x86_64-linux-gnu and i686-linux-gnu (on 5.4 and on 4.15
kernel).
Reviewed-by: Lukasz Majewski <lukma@denx.de>
With arch-syscall.h it can now assumes the existance of either
__NR_sched_rr_get_interval or __NR_sched_rr_get_interval_time64.
The 32-bit time_t support is now only build for
!__ASSUME_TIME64_SYSCALLS.
Checked on x86_64-linux-gnu and i686-linux-gnu (on 5.4 and on 4.15
kernel).
Reviewed-by: Lukasz Majewski <lukma@denx.de>
