It fixes 5fb7fc9635 when posix_spawn fails.
Checked on x86_64-linux-gnu and i686-linux-gnu.
Reviewed-by: Carlos O'Donell <carlos@redhat.com>
(cheery picked from commit f09542c584)
The value of `end_name' points into the value of `dirname', thus don't
deallocate the latter before the last use of the former.
(cherry picked from commit ddc650e9b3)
Linux 5.5 has no new syscalls to add to syscall-names.list, but it
does newly enable the clone3 syscall for AArch64. This patch updates
the kernel version listed in syscall-names.list and regenerates the
AArch64 arch-syscall.h.
Tested with build-many-glibcs.py.
(cherry picked from commit 5828bc4523)
This fixes commit 9333498794 ("Avoid ldbl-96 stack
corruption from range reduction of pseudo-zero (bug 25487).").
(cherry picked from commit c10acd4026)
It seems that some gcc versions might generates a stack frame for the
sigreturn stub requires on sparc signal handling. For instance:
$ cat test.c
#define _GNU_SOURCE
#include <sys/syscall.h>
__attribute__ ((__optimize__ ("-fno-stack-protector")))
void
__sigreturn_stub (void)
{
__asm__ ("mov %0, %%g1\n\t"
"ta 0x10\n\t"
: /* no outputs */
: "i" (SYS_rt_sigreturn));
}
$ gcc -v
[...]
gcc version 9.2.1 20200224 (Debian 9.2.1-30)
$ gcc -O2 -m64 test.c -S -o -
[...]
__sigreturn_stub:
save %sp, -176, %sp
#APP
! 9 "t.c" 1
mov 101, %g1
ta 0x10
! 0 "" 2
#NO_APP
.size __sigreturn_stub, .-__sigreturn_stub
As indicated by kernel developers [1], the sigreturn stub can not change
the register window or the stack pointer since the kernel has setup the
restore frame at a precise location relative to the stack pointer when
the stub is invoked.
I tried to play with some compiler flags and even with _Noreturn and
__builtin_unreachable after the asm does not help (and Sparc does not
support naked functions).
To avoid similar issues, as the stack-protector support also have
stumbled, this patch moves the implementation of the sigreturn stubs to
assembly.
Checked on sparcv9-linux-gnu and sparc64-linux-gnu with gcc 9.2.1
and gcc 7.5.0.
[1] https://lkml.org/lkml/2016/5/27/465
The commit "arm: Split BE/LE abilist"
(1673ba87fe) changed the soft-fp order for
ARM selection when __SOFTFP__ is defined by the compiler.
On 2.30 the sysdeps order is:
2.30
sysdeps/unix/sysv/linux/arm
sysdeps/arm/nptl
sysdeps/unix/sysv/linux
sysdeps/nptl
sysdeps/pthread
sysdeps/gnu
sysdeps/unix/inet
sysdeps/unix/sysv
sysdeps/unix/arm
sysdeps/unix
sysdeps/posix
sysdeps/arm/nofpu
sysdeps/ieee754/soft-fp
sysdeps/arm
sysdeps/wordsize-32
sysdeps/ieee754/flt-32
sysdeps/ieee754/dbl-64
sysdeps/ieee754
sysdeps/generic
While on master is:
sysdeps/unix/sysv/linux/arm/le
sysdeps/unix/sysv/linux/arm
sysdeps/arm/nptl
sysdeps/unix/sysv/linux
sysdeps/nptl
sysdeps/pthread
sysdeps/gnu
sysdeps/unix/inet
sysdeps/unix/sysv
sysdeps/unix/arm
sysdeps/unix
sysdeps/posix
sysdeps/arm/le
sysdeps/arm
sysdeps/wordsize-32
sysdeps/ieee754/flt-32
sysdeps/ieee754/dbl-64
sysdeps/arm/nofpu
sysdeps/ieee754/soft-fp
sysdeps/ieee754
sysdeps/generic
It make the build select some routines (fadd, fdiv, fmul, fsub, and fma)
on ieee754/flt-32 and ieee754/dbl-64 that requires fenv support to be
correctly rounded which in turns lead to math failures since the
__SOFTFP__ does not have fenv support.
With this patch the order is now:
sysdeps/unix/sysv/linux/arm/le
sysdeps/unix/sysv/linux/arm
sysdeps/arm/nptl
sysdeps/unix/sysv/linux
sysdeps/nptlsysdeps/pthread
sysdeps/gnu
sysdeps/unix/inet
sysdeps/unix/sysv
sysdeps/unix/arm
sysdeps/unix
sysdeps/posix
sysdeps/arm/le/nofpu
sysdeps/arm/nofpu
sysdeps/ieee754/soft-fp
sysdeps/arm/le
sysdeps/arm
sysdeps/wordsize-32
sysdeps/ieee754/flt-32
sysdeps/ieee754/dbl-64
sysdeps/ieee754
sysdeps/generic
Checked on arm-linux-gnuaebi.
(cherry picked from commit af09e5e5d9)
The posix_types.h (where __kernel_mode_t is defined) is included
implicitly, which might not happen on older kernels.
(cherry picked from commit 7aec9f4e5e0313772d123ba4daa96ea921a50aec)
The kernel might not clear the padding value for the ipc_perm mode
fields in compat mode (32 bit running on a 64 bit kernel). It was
fixed on v4.14 when the ipc compat code was refactored to move
(commits 553f770ef71b, 469391684626, c0ebccb6fa1e).
Although it is most likely a kernel issue, it was shown only due
BZ#18231 fix which made all the SysVIPC mode_t 32-bit regardless of
the kABI.
This patch fixes it by explicitly zeroing the upper bits for such
cases. The __ASSUME_SYSVIPC_BROKEN_MODE_T case already handles
it with the shift.
(The aarch64 ipc_priv.h is superflous since
__ASSUME_SYSVIPC_DEFAULT_IPC_64 is now defined as default).
Checked on i686-linux-gnu on 3.10 and on 4.15 kernel.
(cherry picked from commit 82025bad80429c67a4d75f098155b5e02b5112b4)
GCC has moved from using .gnu.linkonce for i386 setup pic register with
minimum current version (as for binutils minimum binutils that support
comdat).
Trying to pinpoint when binutils has added comdat support for i686, it
seems it was around 2004 [1]. I also checking with some ancient
binutils older than 2.16 I see:
test.o: In function `__x86.get_pc_thunk.bx':
test.o(.text.__x86.get_pc_thunk.bx+0x0): multiple definition of `__x86.get_pc_thunk.bx'
/usr/lib/gcc/x86_64-linux-gnu/5/../../../i386-linux-gnu/crti.o(.gnu.linkonce.t.__x86.get_pc_thunk.bx+0x0): first defined here
Which seems that such version can not handle either comdat at all or
a mix of linkonce and comdat. For binutils 2.16.1 I am getting a
different issue trying to link a binary with and more recent
ctri.o (unrecognized relocation (0x2b) in section `.init', which is
R_386_GOT32X and old binutils won't generate it anyway).
So I think that either unlikely someone will use an older binutils than
the one used to glibc and even this scenario may fail with some issue
as the R_386_GOT32X. Also, 2.16.1 is quite old and not really supported
(glibc itself required 2.25).
Checked on i686-linux-gnu.
[1] https://gcc.gnu.org/ml/gcc/2004-05/msg00030.html
(cherry picked from commit 35200fd3892f6caf867bf89bc8048e553906af28)
GNU ld's RISCV port does not support IFUNC. ld -no-pie produces no
relocation and the test passed incorrectly. Be more rigid by testing
IRELATIVE explicitly.
Tested-by: Aurelien Jarno <aurelien@aurel32.net>
Reviewed-by: Adhemerval Zanella <adhemerval.zanella@linaro.org>
(cherry picked from commit 87a698a216)
Bug 25487 reports stack corruption in ldbl-96 sinl on a pseudo-zero
argument (an representation where all the significand bits, including
the explicit high bit, are zero, but the exponent is not zero, which
is not a valid representation for the long double type).
Although this is not a valid long double representation, existing
practice in this area (see bug 4586, originally marked invalid but
subsequently fixed) is that we still seek to avoid invalid memory
accesses as a result, in case of programs that treat arbitrary binary
data as long double representations, although the invalid
representations of the ldbl-96 format do not need to be consistently
handled the same as any particular valid representation.
This patch makes the range reduction detect pseudo-zero and unnormal
representations that would otherwise go to __kernel_rem_pio2, and
returns a NaN for them instead of continuing with the range reduction
process. (Pseudo-zero and unnormal representations whose unbiased
exponent is less than -1 have already been safely returned from the
function before this point without going through the rest of range
reduction.) Pseudo-zero representations would previously result in
the value passed to __kernel_rem_pio2 being all-zero, which is
definitely unsafe; unnormal representations would previously result in
a value passed whose high bit is zero, which might well be unsafe
since that is not a form of input expected by __kernel_rem_pio2.
Tested for x86_64.
(cherry picked from commit 9333498794)
If the test fails due some unexpected failure after the children
creation, either in the signal handler by calling abort or in the main
loop; the created children might not be killed properly.
This patches fixes it by:
* Avoid aborting in the signal handler by setting a flag that
an error has occured and add a check in the main loop.
* Add a atexit handler to handle kill child processes.
Checked on x86_64-linux-gnu.
The riscv INTERNAL_SYSCALL macro might clobber the register
parameter if the argument itself might clobber any register (a function
call for instance).
This patch fixes it by using temporary variables for the expressions
between the register assignments (as indicated by GCC documentation,
6.47.5.2 Specifying Registers for Local Variables).
It is similar to the fix done for MIPS (bug 25523).
Checked with riscv64-linux-gnu-rv64imafdc-lp64d build.
(cherry picked from commit be74b42ee2)
The microblaze INTERNAL_SYSCALL macro might clobber the register
parameter if the argument itself might clobber any register (a function
call for instance).
This patch fixes it by using temporary variables for the expressions
between the register assignments (as indicated by GCC documentation,
6.47.5.2 Specifying Registers for Local Variables).
It is similar to the fix done for MIPS (bug 25523).
Checked with microblaze-linux-gnu and microblazeel-linux-gnu build.
(cherry picked from commit 6cc8fc7c15)
According to [gcc documentation][1], temporary variables must be used for
the desired content to not be call-clobbered.
Fix the Linux inline syscall templates by adding temporary variables,
much like what x86 did before
(commit 381a0c26d7).
Tested with gcc 9.2.0, both cross-compiled and natively on Loongson
3A4000.
[1]: https://gcc.gnu.org/onlinedocs/gcc/Local-Register-Variables.html
(cherry picked from commit 4fbba6fe90)
This internal change ideally should not affect the public API or ABI,
but there is a widespread use of seccomp sandboxes, even on 32-bit
targets, that don't handle new Linux syscall usage well, so it's
worth mentioning in the NEWS.
Co-authored-by: Siddhesh Poyarekar <siddhesh@sourceware.org>
Commit 1c3f9acf1f ("nptl: Add struct_mutex.h")
replaced a zero constant with the identifier PTHREAD_MUTEX_DEFAULT
in the macro PTHREAD_MUTEX_INITIALIZER. However, that constant
is not available in ISO C11 mode:
In file included from /usr/include/bits/thread-shared-types.h:74,
from /usr/include/bits/pthreadtypes.h:23,
from /usr/include/pthread.h:26,
from bug25271.c:1:
bug25271.c:3:21: error: ‘PTHREAD_MUTEX_DEFAULT’ undeclared here (not in a function)
3 | pthread_mutex_t m = PTHREAD_MUTEX_INITIALIZER;
| ^~~~~~~~~~~~~~~~~~~~~~~~~
This commit change the constant to the equivalent
PTHREAD_MUTEX_TIMED_NP, which is in the POSIX extension namespace
and thus always available.
In testing glibc for Arm and MIPS, I see:
FAIL: misc/tst-sigcontext-get_pc
If this test - backtracing through a call to raise - is valid, then
raise needs to be built with -fasynchronous-unwind-tables (as the test
itself is) to have the required unwind information for that
backtracing to work. Adding that option, which this patch does,
causes the test for pass for Arm. For MIPS, the test still does not
pass (the backtrace has an address that is 2 bytes after the "address
in signal handler", for unknown reasons), although the patch allows a
longer backtrace to be produced.
The locale/tst-locale-locpath test unsets LANG, then runs a test with
test_wrapper_env and expects LANG to remain unset for that test. This
does not work for cross-testing with cross-test-ssh.sh when sshd (on
the system specified as an argument to cross-test-ssh.sh) is
configured to have a default LANG setting.
The general design used in cross testing, after commit
8540f6d2a7 ("Don't require test wrappers
to preserve environment variables, use more consistent environment.",
6 June 2014), is that environment settings required by tests should be
passed explicitly to $(test-wrapper-env). This patch changes
tst-locale-locpath.sh to pass an explicit LANG= rather than expecting
"unset LANG" to be in effect for the program run under
test_wrapper_env. Note that this does slightly change the environment
in which the test is run natively (empty LANG instead of unset LANG)
but that difference does not appear relevant to what it is trying to
test.
Tested for Arm that this fixes the failure seen for that test in
cross-testing.
As noted in
<https://sourceware.org/ml/libc-alpha/2019-06/msg00824.html>,
elf/tst-rtld-preload fails when cross-testing because it attempts to
run the test wrapper with itself. Unfortunately, that thread never
resulted in a complete and correct patch for that test.
This patch addresses the issues with that test more thoroughly. The
test is changed not to use the wrapper twice, including updating the
message it prints about the command it runs to be more complete and
accurate after the change; the Makefile is changed not to pass the
redundant '$(test-wrapper)' argument.
Tested for Arm that this fixes the failure seen for that test in
cross-testing.
The tests elf/tst-ifunc-fault-bindnow and elf/tst-ifunc-fault-lazy
fail in cross-testing because they run the dynamic linker directly
without using the test wrapper. This patch fixes them to use the test
wrapper instead.
Tested that this fixes the failure of those two tests for powerpc
soft-float.
The ChangeLog automation scripts were incorporated in gnulib as
vcs-to-changelog for a while now since other projects expressed the
desire to use and extend this script. In the interest of avoiding
duplication of code, drop the glibc version of gitlog-to-changelog and
use the gnulib one directly.
The only file that remains is vcstocl_quirks.py, which specifies
properties and quirks of the glibc project source code. This patch
also drops the shebang at the start of vcstocl_quirks.py since the
file is not intended to be directly executable.
The change was introduced in:
commit 33bc9efd91
Author: Dragan Mladjenovic <dmladjenovic@wavecomp.com>
Date: Fri Aug 23 16:38:04 2019 +0000
mips: Force RWX stack for hard-float builds that can run on pre-4.8 kernels
and probably requires a small explanation.
Co-authored-by: Siddhesh Poyarekar <siddhesh@sourceware.org>
When unwinding through a signal frame the backtrace function on PowerPC
didn't check array bounds when storing the frame address. Fixes commit
d400dcac5e ("PowerPC: fix backtrace to handle signal trampolines").
Filip Ochnik spotted that one of the error jumps in gethosts fails to
call __resolv_context_put to release the resolver context.
Fixes commit 352f4ff9a2 ("resolv:
Introduce struct resolv_context [BZ #21668]") and commit
964263bb8d ("getaddrinfo: Release
resolver context on error in gethosts [BZ #21885]").
Reviewed-by: Siddhesh Poyarekar <siddhesh@sourceware.org>
The commit 446997ff14 introduced
this new usage of resplen. If build with gcc 9 -march>=z13 on s390x,
the following warning occurs:
res_send.c: In function ‘__res_context_send’:
res_send.c:539:6: error: ‘resplen’ may be used uninitialized in this function [-Werror=maybe-uninitialized]
539 | if (resplen > HFIXEDSZ)
| ^
Therefore this patch adds a further DIAG_IGNORE_NEEDS_COMMENT in the
same way as it was previously done for usages of resplen or n.
See commit d1bc2cbbed.
The translation project coordinator Benno Schulenberg suggested that
we could save space in our tarball by trimming the generated po files
by using msgattrib and dropping all untranslated, fuzzy and obsolete
messages. This patch updates the update-translations target to do
that. Testing indicates that the current po files reduce by over 65K
lines due to this trimming.
The latest translations in the translationproject URL need to be
merged in using msgmerge for the po files to be correctly updated,
otherwise we may end up getting odd results, such as the previous
translations update. This patch adds another step to the
update-translations Makefile target which does a msgmerge of the
downloaded po file with libc.pot and then uses that as the final
result.
The build has been failing on powerpc64le-linux-gnu with GCC 10
due to a maybe-uninitialized error:
../sysdeps/ieee754/dbl-64/mpa.c:875:6: error: ‘w.e’ may be used
uninitialized in this function [-Werror=maybe-uninitialized]
875 | EY -= EX;
| ^~
The warning is thrown because when __inv is called by __dvd *y is not
initialized and if t == 0 before calling __dbl_mp, EY will stay
uninitialized, as the function does not touch it in this case.
However, since t will be set to 1/t before calling __dbl_mp, t == 0 will
never happen, so we can instruct the compiler to ignore this case, which
suppresses the warning.
Tested on powerpc64le.
Reviewed-by: Tulio Magno Quites Machado Filho <tuliom@linux.ibm.com>
pvalloc is guarantueed to round up the allocation size to the page
size, so applications can assume that the memory region is larger
than the passed-in argument. The alloc_size attribute cannot express
that.
The test case is based on a suggestion from Jakub Jelinek.
This fixes commit 9bf8e29ca1 ("malloc:
make malloc fail with requests larger than PTRDIFF_MAX (BZ#23741)").
Reviewed-by: Adhemerval Zanella <adhemerval.zanella@linaro.org>
This test was failing in some powerpc systems as it was not checking
for ENOSPC return.
As said on the Linux man-pages and can be observed by the implementation
at mm/mprotect.c in the Linux Kernel source. The syscall pkey_alloc can
return EINVAL or ENOSPC. ENOSPC will indicate either that all keys are
in use or that the kernel does not support pkeys.
Reviewed-by: Gabriel F. T. Gomes <gabriel@inconstante.net.br>
GCC 10.0 enabled -fno-common by default and this started to point that
__cache_line_size had been implemented in 2 different places: loader and
libc.
In order to avoid this duplication, the libc variable has been removed
and the loader variable is moved to rtld_global_ro.
File sysdeps/unix/sysv/linux/powerpc/dl-auxv.h has been added in order
to reuse code for both static and dynamic linking scenarios.
Reviewed-by: Carlos O'Donell <carlos@redhat.com>
