| Commit message (Collapse) | Author | Age | Files | Lines |
... | |
|
|
|
|
| |
There is no real need to use a nested function in that test, so break
it out so that it can build with clang too.
|
|
|
|
|
|
|
|
|
|
|
|
| |
The builtin has been available in gcc since 4.7.0 and in clang since
2.6. This fixes stpncpy fortification with clang since it does a
better job of plugging in __stpncpy_chk in the right place than the
header hackery.
This has been tested by building and running all tests with gcc 10.2.1
and also with clang tip as of a few days ago (just the tests in debug/
since running all tests don't work with clang at the moment) to make
sure that both compilers pass the stpncpy tests.
|
|
|
|
|
| |
The NULL check for an array on stack is pointless since it will always
be false, so drop it.
|
|
|
|
|
|
| |
We do not actually need them, so we can move their implementations
into the standard {,f,l}stat{,at} variants and only keep compatibility
wrappers.
|
|
|
|
|
|
| |
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.
|
|
|
|
|
| |
One may send signals immediately after creating a thread. We need to block them
until the thread is ready to run signal handlers.
|
|
|
|
|
| |
pthread_attr_{{get,set}stack{addr,size},setstack} were defining a strong alias
for no reason, turning them to weak.
|
|
|
|
|
| |
If sysconf is used in multithreaded processes, various filedescriptors
may leak due to missing O_CLOEXEC. This commit adds the flag.
|
|
|
|
|
|
|
|
|
|
|
|
| |
__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 0f09154c6400
("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>
|
|
|
|
|
|
|
| |
This adds CFI directives which communicate that the stack ends
with this function.
Fixes bug 26853.
|
|
|
|
|
| |
The EINVAL error code is mandated by POSIX, while ptsname_r returns
ENOTTY, so we need to translate.
|
|
|
|
|
|
|
|
|
| |
* 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 macro is not used anymore, so remove it and warning-nop.c.
Reviewed-by: Florian Weimer <fweimer@redhat.com>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Non-gcc compilers (clang and possibly other compilers that do not
masquerade as gcc 5.0 or later) are unable to use
__warn_memset_zero_len since the symbol is no longer available on
glibc built with gcc 5.0 or later. While it was likely an oversight
that caused this omission, the fact that it wasn't noticed until
recently (when clang closed the gap on _FORTIFY_SUPPORT) that the
symbol was missing.
Given that both gcc and clang are capable of doing this check in the
compiler, drop all remaining signs of __warn_memset_zero_len from
glibc so that no more objects are built with this symbol in future.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The IBM1364, IBM1371, IBM1388, IBM1390 and IBM1399 character sets
share converter logic (iconvdata/ibm1364.c) which would reject
redundant shift sequences when processing input in these character
sets. This led to a hang in the iconv program (CVE-2020-27618).
This commit adjusts the converter to ignore redundant shift sequences
and adds test cases for iconv_prog hangs that would be triggered upon
their rejection. This brings the implementation in line with other
converters that also ignore redundant shift sequences (e.g. IBM930
etc., fixed in commit 692de4b3960d).
Reviewed-by: Carlos O'Donell <carlos@redhat.com>
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
commit def674652eeac60c386d04733318b311f8a5b620
Author: Florian Weimer <fweimer@redhat.com>
Date: Mon Apr 27 15:00:14 2020 +0200
nptl/tst-setuid1-static: Improve isolation from system objects
Static dlopen needs an LD_LIBRARY_PATH setting to avoid loading system
libraries.
missed $(common-objpfx)nss. Add $(common-objpfx)nss to LD_LIBRARY_PATH
for tst-setuid1-static to support
struct passwd *pwd = getpwnam ("nobody");
in nptl/tst-setuid1.c.
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|
|
|
|
| |
Signed-off-by: Jonny Grant <jg@jguk.org>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Included among the GCC 11 warnings listed in bug 26687, but not fixed
when that bug was marked as FIXED, are -Warray-bounds warnings in
nis/ypclnt.c. These are all for different calls to the same piece of
code, which already has a comment explaining that the element accessed
is in a common prefix of the various structures. On the basis of that
comment, this patch treats the warning as a false positive and
disables it for that code.
Tested with build-many-glibcs.py for arm-linux-gnueabi, where,
together with my previous two patches, this allows the build of glibc
to complete with GCC 11 (further build failures appear in the
testsuite).
Reviewed-by: DJ Delorie <dj@redhat.com>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Among the warnings causing a glibc build with GCC 11 to fail is one
for a call new_composite_name in setlocale.c. The newnames argument
is declared as an array with __LC_LAST elements, but when the category
argument is not LC_ALL, it actually only has one element. Since the
number of elements depends on the first argument to the function, it
seems clearer to declare the argument as a pointer.
Tested with build-many-glibcs.py for arm-linux-gnueabi, where this
allows the build to get further.
Reviewed-by: DJ Delorie <dj@redhat.com>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Building glibc with GCC 11 fails with (among other warnings) spurious
-Wstringop-overflow warnings from calls to setjmp and longjmp with a
pointer to a pthread_unwind_buf that is smaller than jmp_buf. As
discussed in bug 26647, the warning in libc-start.c is a false
positive, because setjmp and longjmp do not access anything (the
signal mask) beyond the common prefix of the two structures, so this
patch disables the warning for that call to setjmp, as well as for two
calls in NPTL code that produce the same warning and look like false
positives for the same reason.
Tested with build-many-glibcs.py for arm-linux-gnueabi, where this
allows the build to get further.
Reviewed-by: DJ Delorie <dj@redhat.com>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
malloc debug: fix compile error when enable macro MALLOC_DEBUG > 1.
this is because commit e9c4fe93b3855239752819303ca377dff0ed0553 has change the struct malloc_chunk's member "size" to "mchunk_size".
the reproduction is like that:
setp1: modify related Makefile.
vim ../glibc/malloc/Makefile
CPPFLAGS-malloc.o += -DMALLOC_DEBUG=2
step2: ../configure --prefix=/usr
make -j32
this will cause the compile error:
/home/liqingqing/glibc_upstream/buildglibc/malloc/malloc.o
In file included from malloc.c:1899:0:
arena.c: In function 'dump_heap':
arena.c:422:58: error: 'struct malloc_chunk' has no member named 'size'
fprintf (stderr, "chunk %p size %10lx", p, (long) p->size);
^~
arena.c:428:17: error: 'struct malloc_chunk' has no member named 'size'
else if (p->size == (0 | PREV_INUSE))
Reviewed-by: DJ Delorie <dj@redhat.com>
|
|
|
|
|
|
| |
tst-tcfree2: adjust coding style.
Reviewed-by: DJ Delorie <dj@redhat.com>
|
|
|
|
| |
Reviewed-by: Adhemerval Zanella <adhemerval.zanella@linaro.org>
|
|
|
|
|
|
|
| |
This patch makes build-many-glibcs.py use the new MPC 1.2.1 release.
Tested with build-many-glibcs.py (host-libraries, compilers and glibcs
builds).
|
|
|
|
| |
Suggested-by: David O'Brien <daobrien@redhat.com>
|
|
|
|
|
|
|
| |
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>
|
|
|
|
|
| |
Fixes and partially reverts commit 59803e81f96b479c17f583b31eac44b5
("x86: Optimizing memcpy for AMD Zen architecture.").
|
|
|
|
|
|
|
|
|
|
|
|
| |
The elf/elf.h header is shared, verbatim, by the elfutils project.
However, elfutils can be used on systems with libcs other than glibc,
making the presence of __BEGIN_DECLS, __END_DECLS and <features.h> in
the file something that downstream distros may have to add patches for.
Furthermore, this file doesn't declare anything with language linkage,
so `extern "C" {}` blocks aren't necessary; it also doesn't have any
conditional definitions based on feature test macros, making inclusion
of features.h unnecessary.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|
|
|
|
|
|
|
| |
Add the new constants IP_RECVERR_RFC4884 and IPV6_RECVERR_RFC4884 from
Linux 5.9 to bits/in.h.
Tested for x86_64.
|
|
|
|
|
|
|
|
| |
The explicit error return value (without in-band signaling) avoids
complicated steps to detect errors based on whether errno has been
updated.
Reviewed-by: Alistair Francis <alistair.francis@wdc.com>
|
|
|
|
| |
Now that it was reinstate with 30a0b167d3.
|
|
|
|
|
|
|
|
|
| |
It basically calls the 64-bit __clock_gettime64 and adds the overflow
check.
Checked on x86_64-linux-gnu and i686-linux-gnu.
Reviewed-by: Lukasz Majewski <lukma@denx.de>
|
|
|
|
|
|
|
| |
This patch revert "Move ftime to a compatibility symbol" (commit
14633d3e568eb9770a7e5046eff257113e0453fb).
Checked on x86_64-linux-gnu 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.
|
|
|
|
| |
Reviewed-by: Carlos O'Donell <carlos@redhat.com>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Starting with the commit 04deeaa9ea74b0679dfc9d9155a37b6425f19a9f
"Fix time/tst-cpuclock1 intermitent failures" (2020-07-11),
this test fails quite often on s390x/s390 with one/multiple of those:
"before - after" / "nanosleep time" / "dead - after" ourside reasonable range.
On a zVM/kvm guest the CPUs are shared between multiple guests.
And even on the lpar (kvm host) the CPUs are usually shared between multiple lpars.
The defined CPUs for a lpar/zVM-system could also have lower weights compared
to other lpars which let the steal time further grow.
Usually I build (-j$(nproc)) and test (PARALLELMFLAGS="-j$(nproc)") glibc multiple
times, e.g. with different GCCs, on various lpars or zVM guests at the same time.
During this time, I've run the test for 13500 times and obvserved the following fails:
~600x "before - after"
~60x "nanosleep time"
~70x "dead - after"
I've also observed a lot of "before - after" fails on a intel kvm-guest while
building/testing glibc on it.
The mentioned commit has tighten the limits of valid tv_nsec ranges:
"before - after" (expected: 500000000):
- 100000000 ... 600000000
+ 450000000 ... 550000000
"nanosleep time" (expected: 100000000):
- 100000000 ... 200000000
+ 090000000 ... 120000000
"dead - after" (expected: 100000000):
- ... 200000000
+ 090000000 ... 120000000
The test itself forks a child process which chew_cpu (user- and kernel-space).
The parent process sleeps with nanosleep(0.5s) and measures the child_clock time:
diff = after - before
With much workload on the machine, the child won't make much progess
and it can fall much beyond the minimum limit.
Afterwards the parent process sleeps with clock_nanosleep (child_clock, 0.1s):
diff = afterns - after
The test currently also allows 0.9 * 0.1s which would be an error.
Depending on the workload, the maximum limit can exceed the 1.2 * 0.1s.
For "dead - after", the parent process kills the child process and waits long
enough to let the child finish dying. Then it gets the time of the child:
diff = dead - after
Note that diff also contains the time for the previous clock_nanosleep.
Thus you'll often see both fails at the same time.
After discussion on the mailing list, we've decided to keep the functional
checks for the clock* functions and remove the timing related checks as those
are prone to false positives.
Reviewed-by: Adhemerval Zanella <adhemerval.zanella@linaro.org>
Reviewed-by: Carlos O'Donell <carlos@redhat.com>
|
|
|
|
|
|
|
|
| |
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.
|