about summary refs log tree commit diff
Commit message (Collapse)AuthorAgeFilesLines
* hurd: Notify the proc server later during initializationSamuel Thibault2020-11-113-11/+31
| | | | | | 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.
* htl: Initialize laterSamuel Thibault2020-11-119-122/+32
| | | | | | | | 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.
* htl: Keep thread signals blocked during its initializationSamuel Thibault2020-11-112-2/+13
| | | | | One may send signals immediately after creating a thread. We need to block them until the thread is ready to run signal handlers.
* htl: Fix spurious symbols in namespacesSamuel Thibault2020-11-115-5/+5
| | | | | pthread_attr_{{get,set}stack{addr,size},setstack} were defining a strong alias for no reason, turning them to weak.
* Use O_CLOEXEC in sysconf [BZ #26791]Maximilian Krüger2020-11-111-1/+1
| | | | | If sysconf is used in multithreaded processes, various filedescriptors may leak due to missing O_CLOEXEC. This commit adds the flag.
* struct _Unwind_Exception alignment should not depend on compiler flagsFlorian Weimer2020-11-111-9/+15
| | | | | | | | | | | | __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>
* hurd: keep only required PLTs in ld.soSamuel Thibault2020-11-1117-34/+20
| | | | | | | | | | | | | | | | | | | | | 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.
* hurd: Add missing startup callsSamuel Thibault2020-11-111-0/+16
| | | | | | 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]")
* riscv: Get cache information through sysconfZong Li2020-11-101-0/+100
| | | | | | | | 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>
* RISC-V: Add _dl_start_user.Jim Wilson2020-11-101-1/+3
| | | | | | | | | | | | | 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
* linux: Allow adjtime with NULL argument [BZ #26833]Adhemerval Zanella2020-11-093-4/+54
| | | | | | | | | | | 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>
* aarch64: Add unwind information to _start (bug 26853)Florian Weimer2020-11-091-4/+3
| | | | | | | This adds CFI directives which communicate that the stack ends with this function. Fixes bug 26853.
* bsd unlockpt: unlockpt needs to fail with EINVAL, not ENOTTYSamuel Thibault2020-11-081-1/+6
| | | | | The EINVAL error code is mandated by POSIX, while ptsname_r returns ENOTTY, so we need to translate.
* Rearrange bsd_getpt vs bsd_openpt and implement posix_openpt on BSDSamuel Thibault2020-11-071-10/+8
| | | | | | | | | * 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.
* Remove __warndeclSiddhesh Poyarekar2020-11-053-74/+1
| | | | | | The macro is not used anymore, so remove it and warning-nop.c. Reviewed-by: Florian Weimer <fweimer@redhat.com>
* Remove __warn_memset_zero_len [BZ #25399]Siddhesh Poyarekar2020-11-051-15/+0
| | | | | | | | | | | | | | 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.
* iconv: Accept redundant shift sequences in IBM1364 [BZ #26224]Arjun Shankar2020-11-043-19/+15
| | | | | | | | | | | | | | | 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>
* msg: Remove redundant #include <sys/msg.h> headerLukasz Majewski2020-11-046-6/+0
| | | | | | | | | 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
* tst-setuid1-static-ENV: Add $(common-objpfx)nss [BZ #26820]H.J. Lu2020-11-031-1/+1
| | | | | | | | | | | | | | | | | | 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.
* aarch64: Add variant PCS lazy binding test [BZ #26798]Szabolcs Nagy2020-11-025-0/+288
| | | | | | | | | | | 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.
* aarch64: Fix DT_AARCH64_VARIANT_PCS handling [BZ #26798]Szabolcs Nagy2020-11-021-8/+4
| | | | | | | | | | | | | 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.
* hurd: Correct 'ethenet' spellingJonny Grant2020-10-311-1/+1
| | | | Signed-off-by: Jonny Grant <jg@jguk.org>
* Avoid -Wstringop-overflow warning in pthread_cleanup_push macrosJoseph Myers2020-10-302-10/+35
| | | | | | | | | | | | | | | | | | | | | 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.
* Disable spurious -Warray-bounds for ypclnt.c (bug 26687)Joseph Myers2020-10-301-0/+8
| | | | | | | | | | | | | | | | | 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>
* Do not use array parameter to new_composite_name (bug 26726)Joseph Myers2020-10-301-1/+1
| | | | | | | | | | | | | | 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>
* Disable spurious -Wstringop-overflow for setjmp/longjmp (bug 26647)Joseph Myers2020-10-303-0/+30
| | | | | | | | | | | | | | | | | 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 > 1liqingqing2020-10-301-2/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | 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.liqingqing2020-10-301-4/+4
| | | | | | tst-tcfree2: adjust coding style. Reviewed-by: DJ Delorie <dj@redhat.com>
* elf: In ldconfig, extract the new_sub_entry function from search_dirFlorian Weimer2020-10-301-13/+21
| | | | Reviewed-by: Adhemerval Zanella <adhemerval.zanella@linaro.org>
* Use MPC 1.2.1 in build-many-glibcs.py.Joseph Myers2020-10-301-1/+1
| | | | | | | 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).
* Argument Syntax: Use "option", @option, and @command.Carlos O'Donell2020-10-301-6/+6
| | | | Suggested-by: David O'Brien <daobrien@redhat.com>
* elf: Unify old and new format cache handling code in ld.soFlorian Weimer2020-10-302-146/+158
| | | | | | | 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>
* x86: Restore processing of cache size tunables in init_cacheinfoFlorian Weimer2020-10-281-8/+4
| | | | | Fixes and partially reverts commit 59803e81f96b479c17f583b31eac44b5 ("x86: Optimizing memcpy for AMD Zen architecture.").
* Make elf.h header self contained.Érico Rolim2020-10-281-6/+0
| | | | | | | | | | | | 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.
* x86: Optimizing memcpy for AMD Zen architecture.Sajan Karumanchi2020-10-281-6/+26
| | | | | | | | | | | | | | 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>
* Hurd: Fix ftime buildAdhemerval Zanella2020-10-272-25/+58
| | | | | | | | 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 IP_RECVERR_RFC4884 and IPV6_RECVERR_RFC4884 from Linux 5.9.Joseph Myers2020-10-271-0/+2
| | | | | | | Add the new constants IP_RECVERR_RFC4884 and IPV6_RECVERR_RFC4884 from Linux 5.9 to bits/in.h. Tested for x86_64.
* misc: Add internal __getauxval2 functionFlorian Weimer2020-10-272-6/+32
| | | | | | | | 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>
* Remove NEWS entry about ftime removalAdhemerval Zanella2020-10-271-5/+0
| | | | Now that it was reinstate with 30a0b167d3.
* time: Add 64-bit time_t support for ftimeAdhemerval Zanella2020-10-277-16/+70
| | | | | | | | | 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>
* Reinstate ftime and add deprecate message on ftime usageAdhemerval Zanella2020-10-276-45/+65
| | | | | | | This patch revert "Move ftime to a compatibility symbol" (commit 14633d3e568eb9770a7e5046eff257113e0453fb). Checked on x86_64-linux-gnu and i686-linux-gnu.
* Update kernel version to 5.9 in tst-mman-consts.py.Joseph Myers2020-10-261-1/+1
| | | | | | | | 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.
* Amend grammar and add a descriptionJonny Grant2020-10-261-3/+4
| | | | Reviewed-by: Carlos O'Donell <carlos@redhat.com>
* Fix typo in NEWS fileJonathan Wakely2020-10-261-1/+1
|
* Remove timing related checks of time/tst-cpuclock1Stefan Liebler2020-10-261-59/+6
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
* Update syscall lists for Linux 5.9.Joseph Myers2020-10-2326-2/+28
| | | | | | | | 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.
* Use Linux 5.9 in build-many-glibcs.py.Joseph Myers2020-10-221-1/+1
| | | | | | | This patch makes build-many-glibcs.py use Linux 5.9. Tested with build-many-glibcs.py (host-libraries, compilers and glibcs builds).
* Reword description of SXID_* tunable propertiesSiddhesh Poyarekar2020-10-222-10/+12
| | | | | | | | | | | | | The SXID_* tunable properties only influence processes that are AT_SECURE, so make that a bit more explicit in the documentation and comment. Revisiting the code after a few years I managed to confuse myself, so I imagine there could be others who may have incorrectly assumed like I did that the SXID_ERASE tunables are not inherited by children of non-AT_SECURE processes. Reviewed-by: Florian Weimer <fweimer@redhat.com>
* New benchtest: pthread locksDJ Delorie2020-10-212-1/+556
| | | | | | | | Performance benchmarks for various posix locks: mutex, rwlock, spinlock, condvar, and semaphore. Each test is performed with an empty loop body or with a computationally "interesting" (i.e. difficult to optimize away, and used just to allow lock code to be "hidden" in the filler's CPU cycles).
* y2038: nptl: Provide __futex_clock_wait_bitset64 to support 64 bit bitsetLukasz Majewski2020-10-213-2/+53
| | | | | | | | | | | | | | | The commit: "y2038: nptl: Convert pthread_mutex_{clock|timed}lock to support 64 bit" SHA1: 29e9874a048f47e2d46c40253036c8d2de921548 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>
generated by cgit-pink 1.4.1 (git 2.36.1) at 2024-07-22 23:36:39 +0000