This was likely a mistake in the original aarch64 port copied over
from arm: on aarch64 tpidr_el0 register is always available.
The __read_tp symbol is visible with static linking, but it's not
part of the public ABI so it should be safe to remove.
The -O option avoids interleaving (e.g.) compiler error messages
with other build messages, and makes attribution of messages to
commands easier.
According to my tests, the impact on build time is within the noise.
This patch replaces obsolete AC_TRY_LINK with AC_LINK_IFELSE.
It has been confirmed that GNU 'autoconf' 2.69 doesn't change the
'configure' file and suppressed obsolete warning.
This patch removes obsolete AC_CHECK_TOOL_PREFIX.
It has been confirmed that AC_CHECK_TOOL_PREFIX is defined as NOP in
GNU 'autoconf' 2.69 [1], so we can safely remove it.
The 'configure' file has been deleted one blank line by the 'autoconf'
2.69 command .
[1] autoconf-2.69/share/autoconf/autoconf/programs.m4
181 # AC_CHECK_TOOL_PREFIX
182 # --------------------
183 AU_DEFUN([AC_CHECK_TOOL_PREFIX])
This patch replaces obsoleted AC_HELP_STRING with AS_HELP_STRING.
As of Glibc 2.33, INSTALL says "GNU 'autoconf' 2.69 (exactly)" is
required. So we can safely replace obsoleted macro without worrying
about older autoconf.
This change doesn't affect the contents of "configure" file.
Linux 5.11 has one new syscall, epoll_pwait2. 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 change adds new test to assess mktime's functionality.
To be more specific - following use cases are checked:
- Pass struct tm as epoch time
- Pass struct tm as value just before Y2038 threshold (returned
value shall be 0x7FFFFFFF)
- Pass struct tm as the first value after Y2038 threshold
(expected value - 0x80000000)
Reviewed-by: Adhemerval Zanella <adhemerval.zanella@linaro.org>
This change adds new test to assess difftime's functionality by
adding some arbitrary offsets to current time_t value (read via
time).
If 64 bit time_t is supported, the same procedure is applied around
the threshold of Y2038 time overflow.
Reviewed-by: Adhemerval Zanella <adhemerval.zanella@linaro.org>
This change adds new test to assess ctime's functionality.
To be more specific - following use cases are checked:
- Pass time_t value as 0 to check if epoch time is converted
- Pass time_t as max value for 32 bit systems
- Pass time_t as the first value after Y2038 threshold
Reviewed-by: Adhemerval Zanella <adhemerval.zanella@linaro.org>
This change adds new test to assess sched_rr_get_interval's
functionality.
To be more specific - following use cases are checked:
- If the read interval is correct
- If the proper ABI is used - to check if adjacent data is not
overwritten
Reviewed-by: Adhemerval Zanella <adhemerval.zanella@linaro.org>
If the linux asm/ptrace.h is included before sys/ptrace.h that
breaks the newly added declarations there, so undef the names
that may be defined as macros in the linux header.
The kernel does not put the vDSO at special addresses, so writev can
write the name directly. Also remove the incorrect comment about not
setting l_name.
Andy Lutomirski confirmed in
<https://lore.kernel.org/linux-api/442A16C0-AE5A-4A44-B261-FE6F817EAF3C@amacapital.net/>
that this copy is not necessary.
Reviewed-by: Adhemerval Zanella <adhemerval.zanella@linaro.org>
Remove the extra space between "# endif" left over from
commit f380868f6d
Author: H.J. Lu <hjl.tools@gmail.com>
Date: Thu Dec 24 15:43:34 2020 -0800
Remove _ISOMAC check from <cpu-features.h>
It was added by 1bfbaf7130 where it added a libc_hidden_proto for
__fstatfs but it didn't update the Hurd version as well.
Checked with a build for i686-gnu.
The check is moved to LFS fstatat implementation (since it is the
code that actually implements the syscall).
Reviewed-by: Carlos O'Donell <carlos@redhat.com>
Remove the internal_statvfs64.c and open code the implementation
on internal_statvfs.c. The alpha is now unrequired, the generic
implementation also handles it.
Also, remove unused includes on internal_statvfs.c, and remove
unused arguments on __internal_statvfs{64}.
Reviewed-by: Carlos O'Donell <carlos@redhat.com>
There is no need to handle ENOSYS on fstatfs64 call, required only
for alpha (where is already fallbacks to fstatfs).
Checked on x86_64-linux-gnu.
Reviewed-by: Carlos O'Donell <carlos@redhat.com>
There is no need to handle ENOSYS on fstatfs64 call, required only
for alpha (where is already fallbacks to fstatfs). The wordsize
internal_statvfs64.c is removed, since how the LFS support is
provided by fstatvfs64.c (used on 64-bit architectures as well).
Checked on x86_64-linux-gnu.
Reviewed-by: Carlos O'Donell <carlos@redhat.com>
The __NR_statfs64 syscall is supported on all architectures but
aarch64, mips64, riscv64, and x86_64. And newer ABIs also uses
the new statfs64 interface (where the struct size is used as
second argument).
So the default implementation now uses:
1. __NR_statfs64 for non-LFS call and handle overflow directly
There is no need to handle __NR_statfs since all architectures
that only support are LFS only.
2. __NR_statfs if defined or __NR_statfs64 otherwise for LFS
call.
Alpha is the only outlier, since it is a 64-bit architecture which
provides non-LFS interface and only provides __NR_statfs64 on
newer kernels (v5.1+).
Checked on x86_64-linux-gnu.
Reviewed-by: Carlos O'Donell <carlos@redhat.com>
The __NR_fstatfs64 syscall is supported on all architectures but
aarch64, mips64, riscv64, and x86_64. And newer ABIs also uses
the new fstatfs64 interface (where the struct size is used as
first argument).
So the default implementation now uses:
1. __NR_fstatfs64 for non-LFS call and handle overflow directly
There is no need to handle __NR_fstatfs since all architectures
that only support are LFS only.
2. __NR_fstatfs if defined or __NR_fstatfs64 otherwise for LFS
call.
Alpha is the only outlier, it is a 64-bit architecture which
provides non-LFS interface and only provides __NR_fstatfs64 on
newer kernels (5.1+).
Checked on x86_64-linux-gnu.
Reviewed-by: Carlos O'Donell <carlos@redhat.com>
Currently glibc has three different struct statfs{64} definitions:
1. Non-LFS support where non-LFS and LFS struct have different
size: alpha, arm, hppa, i686, m68k, microblaze, mips (all abis),
powerpc32, s390, sh4, and sparc.
2. Non-LFS support where non-LFS and LFS struct have the same
size: csky and nios2.
3. Only LFS support (where both struct have the same size): arc,
ia64, powerpc64 (including LE), riscv (both 32 and 64 bits),
s390x, sparc64, and x86 (including x32).
The STATFS_IS_STATFS64/__STATFS_MATCHES_STATFS64 does not tell apart
between 1. and 2. since for both the only difference is the struct
size (for 2. both non-LFS and LFS uses the same syscall, where for
1. the old non-LFS is used for [f]statfs).
This patch move the generic statfs.h for both csky and nios2, and
make the default definitions for newer ABIs to assume that only
LFS will be support (so there is no need to keep no-LFS and LFS
struct statfs with the same size, it will be implicit).
This patch does not change the code generation.
Reviewed-by: Carlos O'Donell <carlos@redhat.com>
The XSTAT_IS_XSTAT64 and STAT_IS_KERNEL_STAT flags are now set to 1 and
STATFS_IS_STATFS64 is set to __STATFS_MATCHES_STATFS64. This makes the
default ABI for newer ports to provide only LFS calls.
A copy of non-LFS support is provided to 32-bit ABIS with non-LFS
support (arm, csky, i386, m68k, nios2, s390, and sh). Is also allows
to remove the 64-bit ports, which already uses the default values.
This patch does not change the code generation.
Reviewed-by: Carlos O'Donell <carlos@redhat.com>
aarch64, arc, ia64, mips64, powerpc64, riscv32, riscv64, s390x, sparc64,
and x86_64 defines STATFS_IS_STATFS64 to 0, but all of them alias
statfs to statfs64 and the struct statfs has the same and layout of
struct statfs64.
The correct definition will be used on the [f]statfs[64] consolidation.
This patch does not change code generation since the symbols are
implemented using the auto-generation syscall for all the aforementioned
ABIs.
Reviewed-by: Carlos O'Donell <carlos@redhat.com>
The glibc.malloc.mmap_max tunable as well as al of the INT_32 tunables
don't have use for negative values, so pin the hardcoded limits in the
non-negative range of INT. There's no real benefit in any of those
use cases for the extended range of unsigned, so I have avoided added
a new type to keep things simple.
The TUNABLE_SET interface took a primitive C type argument, which
resulted in inconsistent type conversions internally due to incorrect
dereferencing of types, especialy on 32-bit architectures. This
change simplifies the TUNABLE setting logic along with the interfaces.
Now all numeric tunable values are stored as signed numbers in
tunable_num_t, which is intmax_t. All calls to set tunables cast the
input value to its primitive type and then to tunable_num_t for
storage. This relies on gcc-specific (although I suspect other
compilers woul also do the same) unsigned to signed integer conversion
semantics, i.e. the bit pattern is conserved. The reverse conversion
is guaranteed by the standard.
Add __nonnull((2)) to the setrlimit()/getrlimit() function declaration
to avoid null pointer access.
-----
v2
According to the suggestions of the Adhemerval Zanella and Zack Weinberg:
use __nonnull() to check null pointers in the compilation phase.
do not add pointer check code to setrlimit()/getrlimit().
The validity of the "resource" parameter is checked in the syscall.
v1
https://public-inbox.org/libc-alpha/20201230114131.47589-1-nixiaoming@huawei.com/
-----
Reviewed-by: Adhemerval Zanella <adhemerval.zanella@linaro.org>
This patch updates json "bench-variant" attribute of "bench-memset.c"
to "default" so that the script "benchtests/scripts/plot_strings.py"
can generate a file "memset_time_default_linear.png".
Without this patch, the script "benchtests/scripts/plot_strings.py"
generates a file "memset_time__linear.png" which has inconsistent form
with "memcpy_time_default_linear.png" and
"memmove_time_default_linear.png".
It syncs with gnulib version 1731fef3d. On build_trtable prevent
inlining, so that it doesn't bloat the caller's stack and use auto
variables instead of alloca/malloc.
After these changes, build_trtable's total stack allocation is
only 20 KiB on a 64-bit machine, and this is less than glibc's 64
KiB cutoff so there's little point to using alloca to shrink it.
Checked on x86_64-linux-gnu.
It syncs with gnulib version a8bac4d49. The main changes are:
- Remove the usage of anonymous union within DYNARRAY_STRUCT.
- Use DYNARRAY_FREE instead of DYNARRAY_NAME (free) so that
Gnulib does not change 'free' to 'rpl_free'.
- Use __nonnull instead of __attribute__ ((nonnull ())).
- Use __attribute_maybe_unused__ instead of
__attribute__ ((unused, nonnull (1))).
- Use of _Noreturn instead of _attribute__ ((noreturn)).
The only difference with gnulib is:
--- glibc
+++ gnulib
@@ -18,6 +18,7 @@
#include <dynarray.h>
#include <stdio.h>
+#include <stdlib.h>
void
__libc_dynarray_at_failure (size_t size, size_t index)
@@ -27,7 +28,6 @@
__snprintf (buf, sizeof (buf), "Fatal glibc error: "
"array index %zu not less than array length %zu\n",
index, size);
- __libc_fatal (buf);
#else
abort ();
#endif
It seems a wrong sync from gnulib (the code is used on loader and
thus it requires __libc_fatal instead of abort).
Checked on x86_64-linux-gnu.
It adds __glibc_has_builtin, __glibc_has_extension, and
__attribute_maybe_unused__ alongsize with some fixes.
The differences are:
--- glibc
+++ gnulib
@@ -259,7 +259,9 @@
# define __attribute_const__ /* Ignore */
#endif
-#if __GNUC_PREREQ (2,7) || __glibc_has_attribute (__unused__)
+#if defined __STDC_VERSION__ && 201710L < __STDC_VERSION__
+# define __attribute_maybe_unused__ [[__maybe_unused__]]
+#elif __GNUC_PREREQ (2,7) || __glibc_has_attribute (__unused__)
# define __attribute_maybe_unused__ __attribute__ ((__unused__))
#else
# define __attribute_maybe_unused__ /* Ignore */
@@ -485,7 +487,7 @@
/* The #ifndef lets Gnulib avoid including these on non-glibc
platforms, where the includes typically do not exist. */
-#ifdef __GLIBC__
+#ifndef __WORDSIZE
# include <bits/wordsize.h>
# include <bits/long-double.h>
#endif
The [[__attribute_maybe_unused__]] attribute removal __ is due Joseph
questioning gcc support with -std=c2x or -std=gnu2x [1].
The _WORDSIZE replacement by __GLIBC__ is because it does not play
well with internal cdefs.h that also uses
__LDOUBLE_REDIRECTS_TO_FLOAT128_ABI.
Checked on x86_64-linux-gnu.
[1] https://sourceware.org/pipermail/libc-alpha/2021-January/121600.html
Take in consideration the trailling NULL since sem_search uses
strcmp to compare entries.
Checked on x86_64-linux-gnu and powerpc-linux-gnu (where it triggered
a nptl/tst-sem7 regression).
Linux 5.10 adds PTRACE_PEEKMTETAGS and PTRACE_POKEMTETAGS for AArch64.
Adding those shows up that glibc is also missing PTRACE_SYSEMU and
PTRACE_SYSEMU_SINGLESTEP, for AArch64 (where they were added to Linux
in 5.3) and for PowerPC (where they were added in Linux 4.20); it
already has those two defines for x86. Add all those defines to
glibc's headers.
Tested with build-many-glibcs.py for aarch64-linux-gnu and
powerpc-linux-gnu.
No bug. Just seemed the performance could be improved a bit. Observed
and expected behavior are unchanged. Optimized body of main
loop. Updated page cross logic and optimized accordingly. Made a few
minor instruction selection modifications. No regressions in test
suite. Both test-strchrnul and test-strchr passed.
sem_open already returns EINVAL for input names larger than NAME_MAX,
so it can assume the largest name length with tfind.
Checked on x86_64-linux-gnu.
The internal semaphore list code is moved to a specific file,
sem_routine.c, and the internal usage is simplified to only two
functions (one to insert a new semaphore and one to remove it
from the internal list). There is no need to expose the
internal locking, neither how the semaphore mapping is implemented.
No functional or semantic change is expected, tested on
x86_64-linux-gnu.
Previously, glibc would pick an arbitrary tmpfs file system from
/proc/mounts if /dev/shm was not available. This could lead to
an unsuitable file system being picked for the backing storage for
shm_open, sem_open, and related functions.
This patch introduces a new function, __shm_get_name, which builds
the file name under the appropriate (now hard-coded) directory. It is
called from the various shm_* and sem_* function. Unlike the
SHM_GET_NAME macro it replaces, the callers handle the return values
and errno updates. shm-directory.c is moved directly into the posix
subdirectory because it can be implemented directly using POSIX
functionality. It resides in libc because it is needed by both
librt and nptl/htl.
In the sem_open implementation, tmpfname is initialized directly
from a string constant. This happens to remove one alloca call.
Checked on x86_64-linux-gnu.
