This updates the default GCC version used in build-many-glibcs.py when
no version is specified explicitly. I'm replacing my bot using GCC 8
with one using GCC 10 (leaving the GCC 9 and GCC mainline bots running
as at present).
Those functions allow easy conversion between Y2038 safe, glibc internal
struct __timex64 and struct timex.
Those functions are put in Linux specific sys/timex.h file, as putting
them into glibc's local include/time.h would cause build break on HURD as
it doesn't support struct timex related syscalls.
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 introduced glibc's 'internal' struct __timex64 is a copy of Linux kernel's
struct __kernel_timex (v5.6) introduced for properly handling data for
clock_adjtime64 syscall.
As the struct's __kernel_timex size is the same as for archs with
__WORDSIZE == 64, proper padding and data types conversion (i.e. long to long
long) had to be added for architectures with __WORDSIZE == 32 &&
__TIMESIZE != 64.
Moreover, it stores time in struct __timeval64 rather than struct
timeval, which makes it Y2038-proof.
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 struct __timeval64's definition has been moved from ./include/time.h to
./include/struct___timeval64.h.
This change would prevent from polluting other glibc namespaces (when
headers are modified to support 64 bit time on architectures with
__WORDSIZE==32).
Now it is possible to just include definition of this particular structure
when needed.
Reviewed-by: Alistair Francis <alistair.francis@wdc.com>
Reviewed-by: Adhemerval Zanella <adhemerval.zanella@linaro.org>
The nscd/nscd_helper.c uses __clock_gettime to get current time and on this
basis calculate the relative timeout for poll.
By using __clock_gettime64 on systems with __WORDSIZE == 32 && __TIMESIZE != 64
the timeout is correctly calculated after time_t overflow.
This change brings 64 bit time support to inet deadline related code for
architectures with __WORDSIZE == 32 && __TIMESIZE != 64.
It is also safe to replace struct timespec with struct __timespec64 in
deadline related structures as:
- The __deadline_to_ms () returns the number of miliseconds to deadline to
be used with __poll (and hence it is a relative value).
- To calculate the deadline from timeval (which will be converted latter)
the uintmax_t type is used (unsinged long long int).
Reviewed-by: Adhemerval Zanella <adhemerval.zanella@linaro.org>
For Linux glibc ports the __TIMESIZE == 64 ensures proper aliasing for
__clock_gettime64 (to __clock_gettime).
When __TIMESIZE != 64 (like ARM32, PPC) the glibc expects separate definition
of the __clock_gettime64.
The HURD port only provides __clock_gettime, so this patch adds
__clock_gettime64 as a tiny wrapper on it.
Acked-by: Samuel Thibault <samuel.thibault@ens-lyon.org>
In the glibc project calls to clock_gettime shall be replaced with
__clock_gettime64, which is supporting 64 bit time.
To allow that the __clock_gettime64 needs to be exported as a GLIBC_PRIVATE
symbol.
strcmp is used while resolving PLT references. Vector registers
should not be used during this. The P9 strcmp makes heavy use of
vector registers, so it should be avoided in rtld.
This prevents quiet vector register corruption when glibc is configured
with --disable-multi-arch and --with-cpu=power9. This can be seen with
test-float64x-compat_totalordermag during the first call into
totalordermagf64x@GLIBC_2.27.
Add a guard to fallback to the power8 implementation when building
power9 strcmp for libraries other than libc.
Reviewed-by: Adhemerval Zanella <adhemerval.zanella@linaro.org>
The minimum GCC version has been raised to 6.2 for building
glibc. Therefore, follow the advice inside the implementation
and remove the GCC < 6 codepath.
Likewise, remove the hidden_proto as all internal usages should
inline now.
Adds the access attribute newly introduced in GCC 10 to the subset of
function declarations that are already covered by _FORTIFY_SOURCE and
that don't have corresponding GCC built-in equivalents.
Reviewed-by: DJ Delorie <dj@redhat.com>
We automatically create $(complocaledir) in the testroot.root
now and so we don't need to create it in the test.
Tested on x86_64.
Reviewed-by: DJ Delorie <dj@redhat.com>
In test-conainer we should set errno to 0 before calling strtol,
and check after with TEST_COMPARE.
In tst-support_capture_subprocess we should set errno to 0 before
checking it after the call to strtol.
Tested on x86_64.
Reviewed-by: DJ Delorie <dj@redhat.com>
The new tst-localedef-hardlinks verifies that when compiling
two locales (with default output directory) one with
--no-hard-links and one without the option, results in the
expected behaviour. When --no-hard-links is used the link
counts on LC_CTYPE is 1, indicating that even thoug the two
locale are identical (though different named source files and
output direcotry) the localedef did not carry out the hard
link optimization. Then when --no-hard-links is omitted the
localedef hard link optimization is correctly carried out and
for 2 compiled locales the link count for LC_CTYPE is 2.
Reviewed-by: DJ Delorie <dj@redhat.com>
Expand the support infrastructure:
- Create $(complocaledir) in the testroot.pristine to support localedef.
- Add the variable $complocaledir to script support.
- Add the script command 'mkdirp'.
All localedef tests which run with default paths need to have the
$(complocaledir) created in testroot.pristine. The localedef binary
will not by itself create the default path, but it will write into
the path. By adding this we can simplify the localedef tests.
The variable $complocaledir is the value of the configured
$(complocaledir) which is the location of the compiled locales that
will be searched by the runtime by default.
The command mkdirp will be available in script setup and will
be equivalent to running `mkdir -p`.
The variable and command can be used to write more complex tests.
Reviewed-by: DJ Delorie <dj@redhat.com>
Commit a98dc92dd1 ("x86: Add cache
information support for Zhaoxin processors") introduced an unused
variable warning in the default i686-linux-gnu build:
In file included from ../sysdeps/i386/cacheinfo.c:3:
../sysdeps/x86/cacheinfo.c: In function 'init_cacheinfo':
../sysdeps/x86/cacheinfo.c:762:16: error: unused variable 'eax' [-Werror=unused-variable]
762 | unsigned int eax;
| ^~~
Add a C wrapper to pass arguments in
/* Control process execution. */
extern int prctl (int __option, ...) __THROW;
to prctl syscall:
extern int prctl (int, unsigned long int, unsigned long int,
unsigned long int, unsigned long int);
On platforms where long double may have two different formats, i.e.: the
same format as double (64-bits) or something else (128-bits), building
with -mlong-double-128 is the default and function calls in the user
program match the name of the function in Glibc. When building with
-mlong-double-64, Glibc installed headers redirect such calls to the
appropriate function.
Likewise, the internals of glibc are now built against IEEE long double.
However, the only (minimally) notable usage of long double is difftime.
Reviewed-by: Tulio Magno Quites Machado Filho <tuliom@linux.ibm.com>
GCC 7.5.0 (PR94200) will refuse to compile if both -mabi=% and
-mlong-double-128 are passed on the command line. Surprisingly,
it will work happily if the latter is not. For the sake of
maintaining status quo, test for and blacklist such compilers.
Tested with a GCC 8.3.1 and GCC 7.5.0 compiler for ppc64le.
Reviewed-by: Tulio Magno Quites Machado Filho <tuliom@linux.ibm.com>
This is a small step up from 2.25 which brings in support for
rewriting the .gnu.attributes section of libc/libm.so.
Reviewed-by: Tulio Magno Quites Machado Filho <tuliom@linux.ibm.com>
Add compiler feature tests to ensure we can build ieee128 long double.
These test for -mabi=ieeelongdouble, -mno-gnu-attribute, and -Wno-psabi.
Likewise, verify some compiler bugs have been addressed. These aren't
helpful for building glibc, but may cause test failures when testing
the new long double. See notes below from Raji.
On powerpc64le, some older compiler versions give error for the function
signbit() for 128-bit floating point types. This is fixed by PR83862
in gcc 8.0 and backported to gcc6 and gcc7. This patch adds a test
to check compiler version to avoid compiler errors during make check.
Likewise, test for -mno-gnu-attribute support which was
On powerpc64le, a few files are built on IEEE long double mode
(-mabi=ieeelongdouble), whereas most are built on IBM long double mode
(-mabi=ibmlongdouble, the default for -mlong-double-128). Since binutils
2.31, linking object files with different long double modes causes
errors similar to:
ld: libc_pic.a(s_isinfl.os) uses IBM long double,
libc_pic.a(ieee128-qefgcvt.os) uses IEEE long double.
collect2: error: ld returned 1 exit status
make[2]: *** [../Makerules:649: libc_pic.os] Error 1
The warnings are fair and correct, but in order for glibc to have
support for both long double modes on powerpc64le, they have to be
ignored. This can be accomplished with the use of -mno-gnu-attribute
option when building the few files that require IEEE long double mode.
However, -mno-gnu-attribute is not available in GCC 6, the minimum
version required to build glibc, so this patch adds a test for this
feature in powerpc64le builds, and fails early if it's not available.
Co-Authored-By: Rajalakshmi Srinivasaraghavan <raji@linux.vnet.ibm.com>
Co-Authored-By: Gabriel F. T. Gomes <gabrielftg@linux.ibm.com>
Reviewed-by: Tulio Magno Quites Machado Filho <tuliom@linux.ibm.com>
Improve the commentary to aid future developers who will stumble
upon this novel, yet not always perfect, mechanism to support
alternative formats for long double.
Likewise, rename __LONG_DOUBLE_USES_FLOAT128 to
__LDOUBLE_REDIRECTS_TO_FLOAT128_ABI now that development work
has settled down. The command used was
git grep -l __LONG_DOUBLE_USES_FLOAT128 ':!./ChangeLog*' | \
xargs sed -i 's/__LONG_DOUBLE_USES_FLOAT128/__LDOUBLE_REDIRECTS_TO_FLOAT128_ABI/g'
Reviewed-by: Tulio Magno Quites Machado Filho <tuliom@linux.ibm.com>
GCC 9 has a bug (PR90731) whereby __typeof does not correctly copy
exception specifiers[1]. Surprisingly, this can be quieted by declaring
"#pragma system_header", or if the headers are installed in a system
directory.
Work around this by using the pragma for any gcc version between
9.0 and 9.2 to ensure tests continue to compile.
[1] Example error from g++ 9.2.1:
In file included from ../include/sys/cdefs.h:3,
from ../include/features.h:465,
from ../bits/libc-header-start.h:33,
from ../math/math.h:27,
from ../include/math.h:7,
from test-math-isinff.cc:21:
../libio/bits/stdio-ldbl.h:25:20: error: declaration of ‘int sprintf(char*, const char*, ...)’ has a different exception specifier
25 | __LDBL_REDIR_DECL (sprintf)
| ^~~~~~~
../misc/sys/cdefs.h:461:26: note: in definition of macro ‘__LDBL_REDIR_DECL’
461 | extern __typeof (name) name __asm (__ASMNAME ("__" #name "ieee128"));
| ^~~~
In file included from ../include/stdio.h:5,
from test-math-isinff.cc:22:
../libio/stdio.h:334:12: note: from previous declaration ‘int sprintf(char*, const char*, ...) throw ()’
334 | extern int sprintf (char *__restrict __s,
| ^~~~~~~
Reviewed-by: Tulio Magno Quites Machado Filho <tuliom@linux.ibm.com>
To obtain Zhaoxin CPU cache information, add a new function
handle_zhaoxin().
Add a new function get_common_cache_info() that extracts the code
in init_cacheinfo() to get the value of the variable shared, threads.
Add Zhaoxin branch in init_cacheinfo() for initializing variables,
such as __x86_shared_cache_size.
Since the the U marker can only be applied to 2 unsigned long arguments
in syscalls.list files, add a C wrapper for process_vm_readv and
process_vm_writev syscals which have more than 2 unsigned long arguments.
Update the default typesizes.h to match the new kernel sizes for 32-bit
architectures with a 64-bit time_t and friends. This follows the sizes
used for RV32 which is a y2038 safe architecture added after Linux 5.1.
Reviewed-by: Vineet Gupta <vgupta@synopsys.com>
Tested-by: Vineet Gupta <vgupta@synopsys.com>
Remove the sem-pad.h file and instead have architectures override the
struct semid_ds via the bits/types/struct_semid_ds.h file.
Reviewed-by: Adhemerval Zanella <adhemerval.zanella@linaro.org>
Split out the struct semid_ds into it's own file. This will allow us to
have architectures specify their own version.
Reviewed-by: Adhemerval Zanella <adhemerval.zanella@linaro.org>
Mark unsigned long arguments in mmap, read, recv, recvfrom, send, sendto,
write, ioperm, sendfile64, setxattr, lsetxattr, fsetxattr, getxattr,
lgetxattr, fgetxattr, listxattr, llistxattr and flistxattr with U in
syscalls.list files.
The rseq initialization should happen only for the libc in the base
namespace (in the dynamic case) or the statically linked libc. The
__libc_multiple_libcs flag does not quite cover this case at present,
so this commit introduces a flag argument to __libc_early_init,
indicating whether the libc being libc is the primary one (of the main
program).
Reviewed-by: Carlos O'Donell <carlos@redhat.com>
X32 has 32-bit long and pointer with 64-bit off_t. Since x32 psABI
requires that pointers passed in registers must be zero-extended to
64bit, x32 can share many syscall interfaces with LP64. When a LP64
syscall with long and unsigned long int arguments is used for x32, these
arguments must be properly extended to 64-bit. Otherwise if the upper
32 bits of the register have undefined value, such a syscall will be
rejected by kernel.
For syscalls implemented in assembly codes, 'U' is added to syscall
signature key letters for unsigned long, which is zero-extended to
64-bit types. SYSCALL_ULONG_ARG_1 and SYSCALL_ULONG_ARG_2 are passed
to syscall-template.S for the first and the second unsigned long int
arguments if PSEUDOS_HAVE_ULONG_INDICES is defined. They are used by
x32 to zero-extend 32-bit arguments to 64 bits.
Tested on i386, x86-64 and x32 as well as with build-many-glibcs.py.
Being not familiar with the glibc repository, I typed "make" inside some
subdirectory that has a Makefile, and was met with:
$ make
../Makeconfig:42: *** missing separator. Stop.
At Makeconfig:42, we have:
objdir must be defined by the build-directory Makefile.
Change that to use $(error ...), which I guess was the original
intention. The result is:
$ make
../Makeconfig:42: *** objdir must be defined by the build-directory Makefile. Stop.
This change should not have an effect because the system call was
never defined. Also add the misssing attribute_compat_text_section
attribute to the sstk function (a minor optimization). Also update the
NEWS file to document the change.
Fixes commit 9cc93ba097
("misc: Turn sstk into a compat symbol").
This patch removes the IEEE_DOUBLE_BIG_ENDIAN and
IEEE_DOUBLE_MIXED_ENDIAN macros from gmp-impl.h and gmp-mparam.h, and
the ieee_double_extract union from gmp-impl.h. The macros were used
only in defining the union, which was used nowhere in glibc. As GMP's
gmp-impl.h is over 5000 lines, the file in glibc is so far from the
GMP version that it doesn't seem to make sense to keep things there
that are not relevant in glibc. (I expect there is plenty more in the
header after this patch that is also not relevant in glibc and can be
cleaned up later.)
Tested with build-many-glibcs.py that installed stripped shared
libraries are unchanged by this patch.
On the current AArch64 buildbot the default 20s timeout is not
enough to run this test, it seems
make test t=locale/tst-localedef-path-norm
takes about 25s, so i increased the timeout to 30s.
It is not implemented anywhere. There is an osf_sstk system call on
alpha, but it is not used to implement sstk, and the system call
is not implemented on Linux, either.
New threads inherit the signal mask from the current thread. This
means that signal handlers can run on the newly created thread
immediately after the kernel has created the userspace thread, even
before glibc has initialized the TCB. Consequently, new threads can
observe uninitialized ctype data, among other things.
To address this, block all signals before starting the thread, and
pass the original signal mask to the start routine wrapper. On the
new thread, first perform all thread initialization, and then unblock
signals.
The cost of doing this is two rt_sigprocmask system calls on the old
thread, and one rt_sigprocmask system call on the new thread. (If
there was a way to clone a new thread with a signals disabled, this
could be brought down to one system call each.) The thread descriptor
increases in size, too, and sigset_t is fairly large. This increase
could be brought down by reusing space the in the descriptor which is
not needed before running user code, or by switching to an internal
sigset_t definition which only covers the signals supported by the
kernel definition. (Part of the thread descriptor size increase is
already offset by reduced stack usage in the thread start wrapper
routine after this commit.)
Reviewed-by: Carlos O'Donell <carlos@redhat.com>
During testing of localedef running in a minimal container
there were several error cases which were hard to diagnose
since they appeared as strerror (errno) values printed by the
higher level functions. This change adds three new verbose
messages for potential failure paths. The new messages give
the user the opportunity to use -v and display additional
information about why localedef might be failing. I found
these messages useful myself while writing a localedef
container test for --no-hard-links.
Since the changes cleanup the code that handle codeset
normalization we add tst-localedef-path-norm which contains
many sub-tests to verify the correct expected normalization of
codeset strings both when installing to default paths (the
only time normalization is enabled) and installing to absolute
paths. During the refactoring I created at least one
buffer-overflow which valgrind caught, but these tests did not
catch because the exec in the container had a very clean heap
with zero-initialized memory. However, between valgrind and
the tests the results are clean.
The new tst-localedef-path-norm passes without regression on
x86_64.
Change-Id: I28b9f680711ff00252a2cb15625b774cc58ecb9d
