summary refs log tree commit diff
Commit message (Collapse)AuthorAgeFilesLines
* alpha: Set wait4 as cancellation entrypointAdhemerval Zanella2019-12-302-1/+26
| | | | | | | Since both wait and waitpid are implemented on top of wait4. It fixes nptl/tst-cancel{x}{4,5,7}. Checked on alpha-linux-gnu.
* lv_LV locale: Correct the time part of d_t_fmt (bug 25324)Rafał Lużyński2019-12-301-1/+1
| | | | | | | | | Currently d_t_fmt formats time as "plkst. %H un %M". A quick Google search says that "plkst." means "o’clock" and "un" means "and". Also this format does not display seconds. CLDR does not mention anything like that. We have no reason to use anything different than "%H:%M:%S".
* km_KH locale: Use "%M" instead of "m" in d_t_fmt (bug 25323)Rafał Lużyński2019-12-301-1/+1
| | | | | A quick analysis suggests that the original author meant "%M" (minutes format specifier) instead of "m" which is just a literal "m" letter.
* hurd: Global signal dispositionJeremie Koenig2019-12-2921-163/+386
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This adds _hurd_sigstate_set_global_rcv used by libpthread to enable POSIX-confirming behavior of signals on a per-thread basis. This also provides a sigstate destructor _hurd_sigstate_delete, and a global process signal state, which needs to be locked and check when global disposition is enabled, thus the addition of _hurd_sigstate_lock _hurd_sigstate_actions _hurd_sigstate_pending _hurd_sigstate_unlock helpers. This also updates all the glibc code accordingly. This also drops support for get_int(INIT_SIGMASK), which did not make sense any more since we do not have a single signal thread any more. During fork/spawn, this also reinitializes the child global sigstate's lock. That cures an issue that would very rarely cause a deadlock in the child in fork, tries to unlock ss' critical section lock at the end of fork. This will typically (always?) be observed in /bin/sh, which is not surprising as that is the foremost caller of fork. To reproduce an intermediate state, add an endless loop if _hurd_global_sigstate is locked after __proc_dostop (cast through volatile); that is, while still being in the fork's parent process. When that triggers (use the libtool testsuite), the signal thread has already locked ss (which is _hurd_global_sigstate), and is stuck at hurdsig.c:685 in post_signal, trying to lock _hurd_siglock (which the main thread already has locked and keeps locked until after __task_create). This is the case that ss->thread == MACH_PORT_NULL, that is, a global signal. In the main thread, between __proc_dostop and __task_create is the __thread_abort call on the signal thread which would abort any current kernel operation (but leave ss locked). Later in fork, in the parent, when _hurd_siglock is unlocked in fork, the parent's signal thread can proceed and will unlock eventually the global sigstate. In the client, _hurd_siglock will likewise be unlocked, but the global sigstate never will be, as the client's signal thread has been configured to restart execution from _hurd_msgport_receive. Thus, when the child tries to unlock ss' critical section lock at the end of fork, it will first lock the global sigstate, will spin trying to lock it, which can never be successful, and we get our deadlock. Options seem to be: * Move the locking of _hurd_siglock earlier in post_signal -- but that may generally impact performance, if this locking isn't generally needed anyway? On the other hand, would it actually make sense to wait here until we are not any longer in a critical section (which is meant to disable signal delivery anyway (but not for preempted signals?))? * Clear the global sigstate in the fork's child with the rationale that we're anyway restarting the signal thread from a clean state. This has now been implemented. Why has this problem not been observed before Jérémie's patches? (Or has it? Perhaps even more rarely?) In _S_msg_sig_post, the signal is now posted to a *global receiver thread*, whereas previously it was posted to the *designated signal-receiving thread*. The latter one was in a critical section in fork, so didn't try to handle the signal until after leaving the critical section? (Not completely analyzed and verified.) Another question is what the signal is that is being received during/around the time __proc_dostop executes.
* hurd sendmsg: Fix warning on calling CMSG_*HDRSamuel Thibault2019-12-291-2/+2
|
* hurd: Signal code refactoringJeremie Koenig2019-12-291-112/+160
| | | | | | | | | | | | | This should not change the current behavior, although this fixes a few minor bugs which were made apparent in the process of global signal disposition work: - Split into more functions - Scope variables more restrictively - Split out inner functions - refactor check_pending_signals - make sigsuspend POSIX-conformant. - fix uninitialized act value.
* hurd: Add getcontext, makecontext, setcontext, swapcontextThomas Schwinge2019-12-296-0/+440
| | | | | | | | | | Adapted from the Linux x86 functions. Not thoroughly tested, but manual testing as well as glibc tests look fine, and manual -lpthread testing also looks fine (within the given bounds for a new stack to be used with makecontext). This has also been in use in Debian since 2013.
* hurd: Support sending file descriptors over Unix socketsEmilio Pozuelo Monfort2019-12-292-13/+157
|
* ldbl-128ibm-compat: Do not mix -mabi=*longdouble and -mlong-double-128Gabriel F. T. Gomes2019-12-271-0/+14
| | | | | | | | | | | | | | | Some compiler versions, e.g. GCC 7, complain when -mlong-double-128 is used together with -mabi=ibmlongdouble or -mabi=ieeelongdouble, producing the following error message: cc1: error: ‘-mabi=ibmlongdouble’ requires ‘-mlong-double-128’ This patch removes -mlong-double-128 from the compilation lines that explicitly request -mabi=*longdouble. Tested for powerpc64le. Reviewed-by: Tulio Magno Quites Machado Filho <tuliom@linux.ibm.com>
* ldbl-128ibm-compat: Compiler flags for stdio functionsTulio Magno Quites Machado Filho2019-12-271-0/+6
| | | | | | | | | | | | | | Some of the files that provide stdio.h and wchar.h functions have a filename prefixed with 'io', such as 'iovsprintf.c'. On platforms that imply ldbl-128ibm-compat, these files must be compiled with the flag -mabi=ibmlongdouble. This patch adds this flag to their compilation. Notice that this is not required for the other files that provide similar functions, because filenames that are not prefixed with 'io' have ldbl-128ibm-compat counterparts in the Makefile, which already adds -mabi=ibmlongdouble to them. Reviewed-by: Gabriel F. T. Gomes <gabrielftg@linux.ibm.com>
* Do not redirect calls to __GI_* symbols, when redirecting to *ieee128Tulio Magno Quites Machado Filho2019-12-2710-2/+48
| | | | | | | | | | | | | | | | | | | | | | On platforms where long double has IEEE binary128 format as a third option (initially, only powerpc64le), many exported functions are redirected to their __*ieee128 equivalents. This redirection is provided by installed headers such as stdio-ldbl.h, and is supposed to work correctly with user code. However, during the build of glibc, similar redirections are employed, in internal headers, such as include/stdio.h, in order to avoid extra PLT entries. These redirections conflict with the redirections to __*ieee128, and must be avoided during the build. This patch protects the second redirections with a test for __LONG_DOUBLE_USES_FLOAT128, a new macro that is defined to 1 when functions that deal with long double typed values reuses the _Float128 implementation (this is currently only true for powerpc64le). Tested for powerpc64le, x86_64, and with build-many-glibcs.py. Co-authored-by: Gabriel F. T. Gomes <gabrielftg@linux.ibm.com> Reviewed-by: Florian Weimer <fweimer@redhat.com>
* aarch64: add default memcpy version for kunpeng920Xuelei Zhang2019-12-271-1/+1
| | | | Checked on aarch64-linux-gnu.
* aarch64: ifunc rename for kunpengXuelei Zhang2019-12-274-4/+4
| | | | | | | Rename ifunc for kunpeng to kunpeng920, and modify the corresponding function files including IS_KUNPENG920 judgement. Checked on aarch64-linux-gnu.
* aarch64: Modify error-shown comments for strcpyXuelei Zhang2019-12-271-1/+1
| | | | Checked on aarch64-linux-gnu.
* linux: Consolidate sigprocmaskAdhemerval Zanella2019-12-276-220/+3
| | | | | | | | All architectures now uses the Linux generic implementation which uses __NR_rt_sigprocmask. Checked on x86_64-linux-gnu, sparc64-linux-gnu, ia64-linux-gnu, s390x-linux-gnu, and alpha-linux-gnu.
* Fix return code for __libc_signal_* functionsAdhemerval Zanella2019-12-272-15/+15
| | | | | | | | The functions do not fail regardless of the argument value. Also, for Linux the return value is not correct on some platforms due the missing usage of INTERNAL_SYSCALL_ERROR_P / INTERNAL_SYSCALL_ERRNO macros. Checked on x86_64-linux-gnu, i686-linux-gnu, and sparc64-linux-gnu.
* nptl: Remove duplicate internal __SIZEOF_PTHREAD_MUTEX_T (BZ#25241)Adhemerval Zanella2019-12-261-3/+0
| | | | Checked on x86_64-linux-gnu, i686-linux-gnu, and x86_64-linux-gnu-x32.
* mnw_MM, my_MM, and shn_MM locales: Do not use %OpRafał Lużyński2019-12-233-4/+4
| | | | | The "O" modifier does nothing when used with "%p" so let's better not use it at all and replace "%Op" with "%p".
* Avoid compat symbols for totalorder in powerpc64le IEEE long doubleGabriel F. T. Gomes2019-12-232-0/+18
| | | | | | | | | | | | | | | | | | | | | On powerpc64le, the libm_alias_float128_other_r_ldbl macro is used to create an alias between totalorderf128 and __totalorderlieee128, as well as between the totalordermagf128 and __totalordermaglieee128. However, the totalorder* and totalordermag* functions changed their parameter type since commit ID 42760d764649 and got compat symbols for their old versions. With this change, the aforementioned macro would create two conflicting aliases for __totalorderlieee128 and __totalordermaglieee128. This patch avoids the creation of the alias between the IEEE long double symbols (__totalorderl*ieee128) and the compat symbols, because the IEEE long double functions have never been exported thus don't need such compat symbol. Tested for powerpc64le. Reviewed-by: Joseph Myers <joseph@codesourcery.com>
* ldbl-128ibm-compat: Add *cvt functionsGabriel F. T. Gomes2019-12-236-3/+113
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | This patch adds IEEE long double versions of q*cvt* functions for powerpc64le. Unlike all other long double to/from string conversion functions, these do not rely on internal functions that can take floating-point numbers with different formats and act on them accordingly, instead, the related files are rebuilt with the -mabi=ieeelongdouble compiler flag set. Having -mabi=ieeelongdouble passed to the compiler causes the object files to be marked with a .gnu_attribute that is incompatible with the .gnu_attribute in files built with -mabi=ibmlongdouble (the default). The difference causes error messages similar to the following: ld: libc_pic.a(s_isinfl.os) uses IBM long double, libc_pic.a(ieee128-qefgcvt_r.os) uses IEEE long double. collect2: error: ld returned 1 exit status make[2]: *** [../Makerules:649: libc_pic.os] Error 1 Although this warning is useful in other situations, the library actually needs to have functions with different long double formats, so .gnu_attribute generation is explicitly disabled for these files with the use of -mno-gnu-attribute. Tested for powerpc64le on the branch that actually enables the sysdeps/ieee754/ldbl-128ibm-compat for powerpc64le. Reviewed-by: Paul E. Murphy <murphyp@linux.ibm.com>
* Refactor *cvt functions implementation (2/2)Gabriel F. T. Gomes2019-12-236-59/+62
| | | | | | | | | | | | | | This patch refactors the *cvt functions implementation in a way that makes it easier to re-use them for implementing the IEEE long double on powerpc64le. By removing the macros that generate the function names (APPEND combined with FUNC_PREFIX), the new code makes it easier to define new function names, such as __qecvtieee128. Tested that installed stripped binaries for all build-many-glibcs targets remain identical before and after this patch. Also tested for powerpc64le and x86_64. Reviewed-by: Paul E. Murphy <murphyp@linux.ibm.com>
* Refactor *cvt functions implementation (1/2)Gabriel F. T. Gomes2019-12-238-385/+424
| | | | | | | | | | | | | | | This patch refactors the *cvt functions implementation in a way that makes it easier to re-use them for implementing the IEEE long double on powerpc64le. By splitting the implementation per se in one file (efgcvt-template.c) and the alias definitions in others (e.g. efgcvt.c), the new code makes it easier to define new function names, such as __qecvtieee128. Tested that installed stripped binaries for all build-many-glibcs targets remain identical before and after this patch. Also tested for powerpc64le and x86_64. Reviewed-by: Paul E. Murphy <murphyp@linux.ibm.com>
* Add exception-based flags for wait4Adhemerval Zanella2019-12-201-0/+1
| | | | | | It fixes the tst-cancelx4 and tst-cancelx5 on sparc{64,v9}. Checked on sparc64-linux-gnu and sparcv9-linux-gnu.
* aarch64: Optimized memset for Kunpeng processor.Xuelei Zhang2019-12-194-2/+119
| | | | | | | | | | | | | | | Due to the branch prediction issue of Kunpeng processor, we found memset_generic has poor performance on middle sizes setting, and so we reconstructed the logic, expanded the loop by 4 times in set_long to solve the problem, even when setting below 1K sizes have benefit. Another change is that DZ_ZVA seems no work when setting zero, so we discarded it and used set_long to set zero instead. Fewer branches and predictions also make the zero case have slightly improvement. Checked on aarch64-linux-gnu. Reviewed-by: Wilco Dijkstra <Wilco.Dijkstra@arm.com>
* aarch64: Optimized strlen for strlen_asimdXuelei Zhang2019-12-192-17/+29
| | | | | | | | | | | Optimize the strlen implementation by using vector operations and loop unrolling in main loop.Compared to __strlen_generic,it reduces latency of cases in bench-strlen by 7%~18% when the length of src is greater than 128 bytes, with gains throughout the benchmark. Checked on aarch64-linux-gnu. Reviewed-by: Wilco Dijkstra <Wilco.Dijkstra@arm.com>
* aarch64: Add Huawei Kunpeng to tunable cpu listXuelei Zhang2019-12-193-1/+5
| | | | | | | | | | | Kunpeng processer is a 64-bit Arm-compatible CPU released by Huawei, and we have already signed a copyright assignement with the FSF. This patch adds its to cpu list, and related macro for IFUNC. Checked on aarch64-linux-gnu. Reviewed-by: Szabolcs Nagy <Szabolcs.Nagy@arm.com>
* aarch64: Optimized implementation of memrchrXuelei Zhang2019-12-191-0/+165
| | | | | | | | | | | Considering the excellent performance of memchr.S on glibc 2.30, the same algorithm is used to find chrin. Compared to memrchr.c, this method with memrchr.S achieves an average performance improvement of 58% based on benchtest and its extension cases. Checked on aarch64-linux-gnu. Reviewed-by: Wilco Dijkstra <Wilco.Dijkstra@arm.com>
* aarch64: Optimized implementation of strnlenXuelei Zhang2019-12-191-1/+51
| | | | | | | | | | | Optimize the strlen implementation by using vector operations and loop unrooling in main loop. Compared to aarch64/strnlen.S, it reduces latency of cases in bench-strnlen by 11%~24% when the length of src is greater than 64 bytes, with gains throughout the benchmark. Checked on aarch64-linux-gnu. Reviewed-by: Wilco Dijkstra <Wilco.Dijkstra@arm.com>
* aarch64: Optimized implementation of strcpyXuelei Zhang2019-12-191-32/+27
| | | | | | | | | | | Optimize the strcpy implementation by using vector loads and operations in main loop.Compared to aarch64/strcpy.S, it reduces latency of cases in bench-strlen by 5%~18% when the length of src is greater than 64 bytes, with gains throughout the benchmark. Checked on aarch64-linux-gnu. Reviewed-by: Wilco Dijkstra <Wilco.Dijkstra@arm.com>
* aarch64: Optimized implementation of memcmpXuelei Zhang2019-12-191-53/+79
| | | | | | | | | | | The loop body is expanded from a 16-byte comparison to a 64-byte comparison, and the usage of ldp is replaced by the Post-index mode to the Base plus offset mode. Hence, compare can faster 18% around > 128 bytes in all. Checked on aarch64-linux-gnu. Reviewed-by: Wilco Dijkstra <Wilco.Dijkstra@arm.com>
* Consolidate wait3 implementationsAdhemerval Zanella2019-12-194-83/+1
| | | | | | The generic one calls wait4. Checked on x86_64-linux-gnu.
* Implement waitpid in terms of wait4Adhemerval Zanella2019-12-197-87/+6
| | | | | | This also consolidate all waitpid implementations. Checked on x86_64-linux-gnu.
* linux: Use waitid on wait4 if __NR_wait4 is not definedAdhemerval Zanella2019-12-193-1/+90
| | | | | | | | | | | | | | | | | | | | | | If the wait4 syscall is not available (such as y2038 safe 32-bit systems) waitid should be used instead. However prior Linux 5.4 waitid is not a full superset of other wait syscalls, since it does not include support for waiting for the current process group. It is possible to emulate wait4 by issuing an extra syscall to get the current process group, but it is inherent racy: after the current process group is received and before it is passed to waitid a signal could arrive causing the current process group to change. So waitid is used if wait4 is not defined iff the build is enabled with a minimum kernel if 5.4+. The new assume __ASSUME_WAITID_PID0_P_PGID is added and an error is issued if waitid can not be implemented by either __NR_wait4 or __NR_waitid && __ASSUME_WAITID_PID0_P_PGID. Checked on x86_64-linux-gnu and i686-linux-gnu. Co-authored-by: Alistair Francis <alistair.francis@wdc.com>
* Implement wait in terms of waitpidAdhemerval Zanella2019-12-194-102/+1
| | | | | | | | | The POSIX implementation is used as default and both BSD and Linux version are removed. It simplifies the implementation for architectures that do not provide either __NR_waitpid or __NR_wait4. Checked on x86_64-linux-gnu and powerpc64le-linux-gnu.
* nptl: Move waitpid implementation to libcAdhemerval Zanella2019-12-1929-30/+2
| | | | Checked on x86_64-linux-gnu and powerpc64le-linux-gnu.
* nptl: Move wait implementation to libcAdhemerval Zanella2019-12-1929-57/+2
| | | | Checked on x86_64-linux-gnu and powerpc64le-linux-gnu.
* Remove __waitpid_nocancelAdhemerval Zanella2019-12-196-43/+11
| | | | | | | | | It enables and disables cancellation with pthread_setcancelstate before calling the waitpid. It simplifies the waitpid implementation for architectures that do not provide either __NR_waitpid or __NR_wait4. Checked on x86_64-linux-gnu.
* Fix test isolation for elf/tst-ifunc-fault-lazy, elf/tst-ifunc-fault-bindnowFlorian Weimer2019-12-191-4/+3
| | | | | | | Previously, ld.so was invoked only with the elf subdirectory on the library search path. Since the soname link for libc.so only exists in the top-level build directory, this leaked the system libc into the test.
* Fix __libc_signal_block_all on sparc64Adhemerval Zanella2019-12-191-6/+8
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The posix_spawn on sparc issues invalid sigprocmask calls: rt_sigprocmask(0xffe5e15c /* SIG_??? */, ~[], 0xffe5e1dc, 8) = -1 EINVAL (Invalid argument) Which make support/tst-support_capture_subprocess fails with random output (due the child signal being wrongly captured by the parent). Tracking the culprit it seems to be a wrong code generation in the INTERNAL_SYSCALL due the automatic sigset_t used on __libc_signal_block_all: return INTERNAL_SYSCALL (rt_sigprocmask, err, 4, SIG_BLOCK, &SIGALL_SET, set, _NSIG / 8); Where SIGALL_SET is defined as: ((__sigset_t) { .__val = {[0 ... _SIGSET_NWORDS-1 ] = -1 } }) Building the expanded __libc_signal_block_all on sparc64 with recent compiler (gcc 8.3.1 and 9.1.1): #include <signal> int _libc_signal_block_all (sigset_t *set) { INTERNAL_SYSCALL_DECL (err); return INTERNAL_SYSCALL (rt_sigprocmask, err, 4, SIG_BLOCK, &SIGALL_SET, set, _NSIG / 8); } The first argument (SIG_BLOCK) is not correctly set on 'o0' register: __libc_signal_block_all: save %sp, -304, %sp add %fp, 1919, %o0 mov 128, %o2 sethi %hi(.LC0), %o1 call memcpy, 0 or %o1, %lo(.LC0), %o1 add %fp, 1919, %o1 mov %i0, %o2 mov 8, %o3 mov 103, %g1 ta 0x6d; bcc,pt %xcc, 1f mov 0, %g1 sub %g0, %o0, %o0 mov 1, %g1 1: sra %o0, 0, %i0 return %i7+8 nop Where if SIGALL_SET is defined a const object, gcc correctly sets the expected kernel argument in correct register: sethi %hi(.LC0), %o1 call memcpy, 0 or %o1, %lo(.LC0), %o1 -> mov 1, %o0 add %fp, 1919, %o1 Another possible fix is use a static const object. Although there should not be a difference between a const compound literal and a static const object, the gcc C99 status page [1] has a note stating that this optimization is not implemented: "const-qualified compound literals could share storage with each other and with string literals, but currently don't.". This patch fixes it by moving both sigset_t that represent the signal sets to static const data object. It generates slight better code where the object reference is used directly instead of a stack allocation plus the content materialization. Checked on x86_64-linux-gnu, i686-linux-gnu, and sparc64-linux-gnu. [1] https://gcc.gnu.org/c99status.html
* powerpc: Do not run IFUNC resolvers for LD_DEBUG=unused [BZ #24214]Adhemerval Zanella2019-12-192-4/+6
| | | | | | | | | | | This patch adds the missing bits for powerpc and fixes both tst-ifunc-fault-lazy and tst-ifunc-fault-bindnow failures on powerpc-linux-gnu. Checked on powerpc-linux-gnu and powerpc-linux-gnu-power4. Reviewed-by: Florian Weimer <fweimer@redhat.com> Reviewed-by: Tulio Magno Quites Machado Filho <tuliom@linux.ibm.com>
* hurd: Do not make sigprocmask available in ld.soFlorian Weimer2019-12-183-11/+2
| | | | | | | | | | | After commit f7649d5780aa4682393b9daedd653e4d9c12784c ("dlopen: Do not block signals"), the dynamic linker no longer uses sigprocmask, which means that it does not have to be made available explicitly on hurd. This reverts commit 892badc9bbcd4a6f8c2eb6c8a99be3aa22517532 ("hurd: Make __sigprocmask GLIBC_PRIVATE") and commit d5ed9ba29a3c818b3433a1784862494968abda45 ("hurd: Fix ld.so link"), but keeps the comment changes from the second commit.
* build-many-glibcs.py: Do not build C++ PCHs by defaultFlorian Weimer2019-12-181-2/+5
| | | | | They are not used during the subsequent glibc build, so creating them merely wastes time.
* hurd: Make getrandom honour GRND_NONBLOCKJames Clarke2019-12-171-1/+5
| | | | | | * sysdeps/mach/hurd/getrandom.c (__getrandom): Open the random source with O_NONBLOCK when the GRND_NONBLOCK flag is provided. Message-Id: <20191217182929.90989-1-jrtc27@jrtc27.com>
* tunables: report sbrk() failureDJ Delorie2019-12-161-5/+4
| | | | Reviewed-by: Carlos O'Donell <carlos@redhat.com>
* build-many-glibcs.py: Add mipsisa64r6el-linux-gnu targetDragan Mladjenovic2019-12-161-0/+11
| | | | | This patch enables building mips/r6 isa/little-endian/hard-float configuration in o32, n32, and n64 variants.
* mips: Do not include hi and lo in __SYSCALL_CLOBBERS for R6Dragan Mladjenovic2019-12-163-6/+21
| | | | | | | | | | | | | | | | | | | GCC 10 (PR 91233) won't silently allow registers that are not architecturally available to be present in the clobber list anymore, resulting in build failure for mips*r6 targets in form of: ... .../sysdep.h:146:2: error: the register ‘lo’ cannot be clobbered in ‘asm’ for the current target 146 | __asm__ volatile ( \ | ^~~~~~~ This is because base R6 ISA doesn't define hi and lo registers w/o DSP extension. This patch provides the alternative definitions of __SYSCALL_CLOBBERS for r6 targets that won't include those registers. * sysdeps/unix/sysv/linux/mips/mips32/sysdep.h (__SYSCALL_CLOBBERS): Exclude hi and lo from the clobber list for __mips_isa_rev >= 6. * sysdeps/unix/sysv/linux/mips/mips64/n32/sysdep.h (__SYSCALL_CLOBBERS): Likewise. * sysdeps/unix/sysv/linux/mips/mips64/n64/sysdep.h (__SYSCALL_CLOBBERS): Likewise.
* ldbl-128ibm-compat: Add ISO C99 versions of scanf functionsGabriel F. T. Gomes2019-12-1322-39/+522
| | | | | | | | | | | | | | | In the format string for *scanf functions, the '%as', '%aS', and '%a[]' modifiers behave differently depending on ISO C99 compatibility. When _GNU_SOURCE is defined and -std=c89 is passed to the compiler, these functions behave like ascanf, and the modifiers allocate memory for the output. Otherwise, the ISO C99 compliant version of these functions is used, and the modifiers consume a floating-point argument. This patch adds the IEEE binary128 variant of ISO C99 compliant functions for the third long double format on powerpc64le. Tested for powerpc64le. Reviewed-by: Paul E. Murphy <murphyp@linux.ibm.com>
* ldbl-128ibm-compat: Fix selection of GNU and ISO C99 scanfGabriel F. T. Gomes2019-12-133-4/+12
| | | | | | | | | | | | | | | | | | | | | Since commit commit 03992356e6fedc5a5e9d32df96c1a2c79ea28a8f Author: Zack Weinberg <zackw@panix.com> Date: Sat Feb 10 11:58:35 2018 -0500 Use C99-compliant scanf under _GNU_SOURCE with modern compilers. the selection of the GNU versions of scanf functions requires both _GNU_SOURCE and -std=c89. This patch changes the tests in ldbl-128ibm-compat so that they actually test the GNU versions (without this change, the redirection to the ISO C99 version always happens, so GNU versions of the new implementation (e.g. __scanfieee128) were left untested). Tested for powerpc64le. Reviewed-by: Paul E. Murphy <murphyp@linux.ibm.com>
* hurd: Fix local PLTSamuel Thibault2019-12-135-6/+23
| | | | | | | | | | * include/sys/random.h (__getrandom): Add hidden prototype. * stdlib/getrandom.c (getrandom): Rename to hidden definition __getrandom. Add weak alias. * sysdeps/mach/hurd/getrandom.c (getrandom): Likewise. * sysdeps/unix/sysv/linux/getrandom.c (getrandom): Likewise. * sysdeps/mach/hurd/getentropy.c (getentropy): Use __getrandom instead of getrandom.
* dlopen: Do not block signalsFlorian Weimer2019-12-131-26/+11
| | | | | | | | | | | | | | | | | | Blocking signals causes issues with certain anti-malware solutions which rely on an unblocked SIGSYS signal for system calls they intercept. This reverts commit a2e8aa0d9ea648068d8be52dd7b15f1b6a008e23 ("Block signals during the initial part of dlopen") and adds comments related to async signal safety to active_nodelete and its caller. Note that this does not make lazy binding async-signal-safe with regards to dlopen. It merely avoids introducing new async-signal-safety hazards as part of the NODELETE changes. Reviewed-by: Adhemerval Zanella <adhemerval.zanella@linaro.org> Reviewed-by: Carlos O'Donell <carlos@redhat.com>
generated by cgit-pink 1.4.1 (git 2.36.1) at 2024-11-27 04:04:18 +0000