about summary refs log tree commit diff
Commit message (Collapse)AuthorAgeFilesLines
* sl_SI locale: Use "." as the thousands separator (bug 25233)Rafał Lużyński2020-01-081-2/+2
| | | | | | | | | | This is correct according to CLDR [1] and Florian Weimer's quick research. [2] [1] https://st.unicode.org/cldr-apps/v#/sl/Symbols/ [2] https://sourceware.org/bugzilla/show_bug.cgi?id=25233#c0 Reviewed-by: Siddhesh Poyarekar <siddhesh@sourceware.org>
* Fix formatting of ChangeLog ouputSiddhesh Poyarekar2020-01-071-1/+1
| | | | | | Add another newline when the number of files differing is too large. This is typical for across-the-board changes such as the copyright year update that happened recently.
* hurd: Fix message reception for timer_threadSamuel Thibault2020-01-051-1/+2
| | | | | | | Without a proper size, we get MACH_RCV_TOO_LARGE instead of MACH_MSG_SUCCESS. * sysdeps/mach/hurd/setitimer.c (timer_thread): Add return_code_type field to received message, and set the receive size in __mach_msg call.
* htl: Add __errno_location and __h_errno_locationSamuel Thibault2020-01-045-0/+42
| | | | | | | | As explained on https://sourceware.org/ml/libc-alpha/2020-01/msg00049.html the presence of __errno_location in libpthread.so on GNU/Linux makes libpthread getting linked in for libstdc++. This aligns on that behavior, to avoid issues that only GNU/Hurd would get.
* htl: Move pthread_atfork to libc_nonshared.aSamuel Thibault2020-01-043-34/+6
| | | | | | | | | | | | | | | This follows bd60ce86520b ('nptl: Move pthread_atfork to libc_nonshared.a') with the same rationale: there is no non-libpthread equivalent to be used for making linking against libpthread optional. libpthread_nonshared.a is unused after this, so remove it from the build. There is no ABI impact because pthread_atfork was implemented using __register_atfork in libc even before this change. pthread_atfork has to be a weak alias because pthread_* names are not reserved in libc.
* htl: Drop common tcbhead_t definitionSamuel Thibault2020-01-041-10/+2
| | | | | This would conflict when including pt-internal.h outside libpthread, while we can actually just include <tls.h>
* htl: Use dso_handle.hSamuel Thibault2020-01-041-5/+2
|
* linux: Optimize fallback 32-bit clock_getresAdhemerval Zanella2020-01-031-4/+12
| | | | | | | | | | | | | | | | | | | | | | | | This patch avoid probing the __NR_clock_getttime64 syscall each time __clock_gettime64 is issued on a kernel without 64 bit time support. Once ENOSYS is obtained, only 32-bit clock_gettime are used. The following snippet: clock_getres (CLOCK_REALTIME, &(struct timespec) { 0 }); clock_getres (CLOCK_MONOTONIC, &(struct timespec) { 0 }); clock_getres (CLOCK_BOOTTIME, &(struct timespec) { 0 }); clock_getres (20, &(struct timespec) { 0 }); On a kernel without 64 bit time support issues the syscalls: syscall_0x196(0, 0xffb83330, [...]) = -1 ENOSYS (Function not implemented) clock_getres(CLOCK_REALTIME, {tv_sec=0, tv_nsec=1}) = 0 clock_getres(CLOCK_MONOTONIC, {tv_sec=0, tv_nsec=1}) = 0 clock_getres(CLOCK_BOOTTIME, {tv_sec=0, tv_nsec=1}) = 0 Checked on i686-linux-gnu on 4.15 kernel. Reviewed-by: Siddhesh Poyarekar <siddhesh@sourceware.org>
* linux: Add support for clock_getres64 vDSOAdhemerval Zanella2020-01-038-12/+24
| | | | | | | | No architecture currently defines the vDSO symbol. On archictures with 64-bit time_t the HAVE_CLOCK_GETRES_VSYSCALL is renamed to HAVE_CLOCK_GETRES64_VSYSCALL, it simplifies clock_gettime code. Reviewed-by: Siddhesh Poyarekar <siddhesh@sourceware.org>
* linux: Enable vDSO clock_gettime64 for mipsAdhemerval Zanella2020-01-031-0/+5
| | | | | | It was added on Linux 5.4 (commit 1f66c45db3302). Reviewed-by: Siddhesh Poyarekar <siddhesh@sourceware.org>
* linux: Enable vDSO clock_gettime64 for armAdhemerval Zanella2020-01-031-0/+1
| | | | | | It was added on Linux 5.5 (commit 74d06efb9c2f9). Reviewed-by: Siddhesh Poyarekar <siddhesh@sourceware.org>
* linux: Enable vDSO clock_gettime64 for i386Adhemerval Zanella2020-01-031-0/+1
| | | | | | | | It was added on Linux 5.3 (commit 22ca962288c0a). Checked on i686-linux-gnu with 5.3.0 kernel. Reviewed-by: Siddhesh Poyarekar <siddhesh@sourceware.org>
* linux: Optimize fallback 32-bit clock_gettimeAdhemerval Zanella2020-01-031-4/+12
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This patch avoid probing the __NR_clock_getttime64 syscall each time __clock_gettime64 is issued on a kernel without 64 bit time support. Once ENOSYS is obtained, only 32-bit clock_gettime are used. The following snippet: clock_gettime (CLOCK_REALTIME, &(struct timespec) { 0 }); clock_gettime (CLOCK_MONOTONIC, &(struct timespec) { 0 }); clock_gettime (CLOCK_BOOTTIME, &(struct timespec) { 0 }); clock_gettime (20, &(struct timespec) { 0 }); On a kernel without 64 bit time support and with vDSO support results on the following syscalls: syscall_0x193(0, 0xff87ba30, [...]) = -1 ENOSYS (Function not implemented) clock_gettime(CLOCK_BOOTTIME, {tv_sec=927082, tv_nsec=474382032}) = 0 clock_gettime(0x14 /* CLOCK_??? */, 0xff87b9f8) = -1 EINVAL (Invalid argument) While on a kernel without vDSO support: syscall_0x193(0, 0xbec95550, 0xb6ed2000, 0x1, 0xbec95550, 0) = -1 (errno 38) clock_gettime(CLOCK_REALTIME, {tv_sec=1576615930, tv_nsec=638250162}) = 0 clock_gettime(CLOCK_MONOTONIC, {tv_sec=1665478, tv_nsec=638779620}) = 0 clock_gettime(CLOCK_BOOTTIME, {tv_sec=1675418, tv_nsec=292932704}) = 0 clock_gettime(0x14 /* CLOCK_??? */, 0xbec95530) = -1 EINVAL (Invalid argument) Checked on i686-linux-gnu on 4.15 kernel and on a 5.3 kernel. Reviewed-by: Siddhesh Poyarekar <siddhesh@sourceware.org>
* linux: Add support for clock_gettime64 vDSOAdhemerval Zanella2020-01-039-12/+34
| | | | | | | | No architecture currently defines the vDSO symbol. On architectures with 64-bit time_t the HAVE_CLOCK_GETTIME_VSYSCALL is renamed to HAVE_CLOCK_GETTIME64_VSYSCALL, it simplifies clock_gettime code. Reviewed-by: Siddhesh Poyarekar <siddhesh@sourceware.org>
* elf: Move vDSO setup to rtld (BZ#24967)Adhemerval Zanella2020-01-0331-289/+257
| | | | | | | | | | | | | | | | | | | | | | | | This patch moves the vDSO setup from libc to loader code, just after the vDSO link_map setup. For static case the initialization is moved to _dl_non_dynamic_init instead. Instead of using the mangled pointer, the vDSO data is set as attribute_relro (on _rtld_global_ro for shared or _dl_vdso_* for static). It is read-only even with partial relro. It fixes BZ#24967 now that the vDSO pointer is setup earlier than malloc interposition is called. Also, vDSO calls should not be a problem for static dlopen as indicated by BZ#20802. The vDSO pointer would be zero-initialized and the syscall will be issued instead. Checked on x86_64-linux-gnu, i686-linux-gnu, aarch64-linux-gnu, arm-linux-gnueabihf, powerpc64le-linux-gnu, powerpc64-linux-gnu, powerpc-linux-gnu, s390x-linux-gnu, sparc64-linux-gnu, and sparcv9-linux-gnu. I also run some tests on mips. Reviewed-by: Siddhesh Poyarekar <siddhesh@sourceware.org>
* elf: Enable relro for static buildAdhemerval Zanella2020-01-031-4/+14
| | | | | | | | | | | | | | | | | | | | | The code is similar to the one at elf/dl-reloc.c, where it checks for the l_relro_size from the link_map (obtained from PT_GNU_RELRO header from program headers) and calls_dl_protected_relro. For testing I will use the ones proposed by Florian's patch 'elf: Add tests for working RELRO protection' [1]. Checked on x86_64-linux-gnu, i686-linux-gnu, powerpc64le-linux-gnu, aarch64-linux-gnu, s390x-linux-gnu, and sparc64-linux-gnu. I also check with --enable-static pie on x86_64-linux-gnu, i686-linux-gnu, and aarch64-linux-gnu which seems the only architectures where static PIE is actually working (as per 9d7a3741c9e, on arm-linux-gnueabihf, powerpc64{le}-linux-gnu, and s390x-linux-gnu I am seeing runtime issues not related to my patch). [1] https://sourceware.org/ml/libc-alpha/2019-10/msg00059.html Reviewed-by: Siddhesh Poyarekar <siddhesh@sourceware.org>
* linux: Consolidate time implementationAdhemerval Zanella2020-01-033-55/+54
| | | | | | | | | | | The IFUNC bypass to vDSO is used when USE_IFUNC_TIME is set. Currently powerpc and x86 defines it. Otherwise the generic implementation is used, which calls clock_gettime. Checked on powerpc64le-linux-gnu, powerpc64-linux-gnu, powerpc-linux-gnu-power4, x86_64-linux-gnu, and i686-linux-gnu. Reviewed-by: Siddhesh Poyarekar <siddhesh@sourceware.org>
* linux: Consolidate Linux gettimeofdayAdhemerval Zanella2020-01-034-100/+63
| | | | | | | | | | | | The IFUNC bypass to vDSO is used when USE_IFUNC_GETTIMEOFDAY is set. Currently aarch64, powerpc*, and x86 defines it. Otherwise the generic implementation is used, which calls clock_gettime. Checked on aarch64-linux-gnu, powerpc64le-linux-gnu, powerpc64-linux-gnu, powerpc-linux-gnu-power4, x86_64-linux-gnu, and i686-linux-gnu. Reviewed-by: Siddhesh Poyarekar <siddhesh@sourceware.org>
* linux: Update mips vDSO symbolsAdhemerval Zanella2020-01-031-0/+1
| | | | | | | | | The clock_getres is a new implementation added on Linux 5.4 (abed3d826f2f). Checked with a build against mips-linux-gnu and mips64-linux-gnu. Reviewed-by: Siddhesh Poyarekar <siddhesh@sourceware.org>
* linux: Update x86 vDSO symbolsAdhemerval Zanella2020-01-033-4/+4
| | | | | | | | | | | | | Add the missing time and clock_getres vDSO symbol names on x86. For time, the iFUNC already uses expected name so it affects only the static build. The clock_getres is a new implementation added on Linux 5.3 (f66501dc53e72). Checked on x86-linux-gnu and i686-linux-gnu. Reviewed-by: Siddhesh Poyarekar <siddhesh@sourceware.org>
* Remove vDSO support from make-syscall.shAdhemerval Zanella2020-01-031-44/+1
| | | | | | | | | | | | | | | | | The auto-generated vDSO call shows some issues: - It requires sync the auto-generated C file with current glibc implementation; - It still uses symbol redirections hacks where libc-symbols.h provide macros that uses compiler builtins (libc_ifunc_redirected for instance); - It does not handle all required compiler handling (inhibit_stack_protector on iFUNC resolver). - No architecure uses it. Checked with a build against all major ABIs. Reviewed-by: Siddhesh Poyarekar <siddhesh@sourceware.org>
* x86: Make x32 use x86 time implementationAdhemerval Zanella2020-01-032-2/+0
| | | | | | | | | | This is the only use of auto-generation syscall which uses a vDSO plus IFUNC and the current x86 generic implementation already covers the expected semantic. Checked on x86_64-linux-gnu-x32. Reviewed-by: Siddhesh Poyarekar <siddhesh@sourceware.org>
* linux: Fix vDSO macros build with time64 interfacesAdhemerval Zanella2020-01-0310-98/+58
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | As indicated on libc-help [1] the ec138c67cb commit broke 32-bit builds when configured with --enable-kernel=5.1 or higher. The scenario 10 from [2] might also occur in this configuration and INLINE_VSYSCALL will try to use the vDSO symbol and HAVE_CLOCK_GETTIME64_VSYSCALL does not set HAVE_VSYSCALL prior its usage. Also, there is no easy way to just enable the code to use one vDSO symbol since the macro INLINE_VSYSCALL is redefined if HAVE_VSYSCALL is set. Instead of adding more pre-processor handling and making the code even more convoluted, this patch removes the requirement of defining HAVE_VSYSCALL before including sysdep-vdso.h to enable vDSO usage. The INLINE_VSYSCALL is now expected to be issued inside a HAVE_*_VSYSCALL check, since it will try to use the internal vDSO pointers. Both clock_getres and clock_gettime vDSO code for time64_t were removed since there is no vDSO setup code for the symbol (an architecture can not set HAVE_CLOCK_GETTIME64_VSYSCALL). Checked on i686-linux-gnu (default and with --enable-kernel=5.1), x86_64-linux-gnu, aarch64-linux-gnu, and powerpc64le-linux-gnu. I also checked against a build to mips64-linux-gnu and sparc64-linux-gnu. [1] https://sourceware.org/ml/libc-help/2019-12/msg00014.html [2] https://sourceware.org/ml/libc-alpha/2019-12/msg00142.html Reviewed-by: Siddhesh Poyarekar <siddhesh@sourceware.org>
* Linux: Fix clock_nanosleep time64 checkAdhemerval Zanella2020-01-031-8/+12
| | | | | | | | The result of INTERNAL_SYSCALL_CANCEL should be checked with macros INTERNAL_SYSCALL_ERROR_P and INTERNAL_SYSCALL_ERRNO instead of comparing the result directly. Checked on powerpc-linux-gnu.
* Add libm_alias_finite for _finite symbolsWilco Dijkstra2020-01-03263-351/+605
| | | | | | | | | | | | | | | | | | | This patch adds a new macro, libm_alias_finite, to define all _finite symbol. It sets all _finite symbol as compat symbol based on its first version (obtained from the definition at built generated first-versions.h). The <fn>f128_finite symbols were introduced in GLIBC 2.26 and so need special treatment in code that is shared between long double and float128. It is done by adding a list, similar to internal symbol redifinition, on sysdeps/ieee754/float128/float128_private.h. Alpha also needs some tricky changes to ensure we still emit 2 compat symbols for sqrt(f). Passes buildmanyglibc. Co-authored-by: Adhemerval Zanella <adhemerval.zanella@linaro.org> Reviewed-by: Siddhesh Poyarekar <siddhesh@sourceware.org>
* Update libc.pot for 2.31 releaseSiddhesh Poyarekar2020-01-021-70/+66
|
* Multiple locales: Add date_fmt (bug 24054)Rafał Lużyński2020-01-02204-203/+564
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | It is not specified what should be the content of d_t_fmt and date_fmt but in the built-in C locale those fields have only one difference: date_fmt contains "%Z" (the current time zone) while d_t_fmt does not. For most of the locales this commit does the following operation: copy d_t_fmt to date_fmt, and then remove "%Z" from d_t_fmt. If "%Z" was originally missing from d_t_fmt add it to date_fmt. It also corrects comments where necessary. Exceptions: * In bo_CN, dz_BT, and km_KH "%Z" has not been added to date_fmt because it was too difficult. In these locales date_fmt has been set to the copy of d_t_fmt. * In en_DK "%Z" has not been removed from d_t_fmt in order to preserve the conformance with the standard mentioned in the comment. The command to identify and initially edit the locales that need the update was: for i in `grep -lw d_t_fmt *` do if ! grep -qw date_fmt $i ; then awk '/d_t_fmt/ { print $0; gsub("d_t_fmt", "date_fmt"); } //{ print $0 }' < $i > $i.next mv $i.next $i fi done and then each file was further edited manually.
* build-many-glibcs.py: Fix “glibcs i686-gnu --strip”Florian Weimer2020-01-021-4/+9
| | | | | | Hurd uses an empty prefix, so the linker scripts end up in /lib, the find command picked them up, and stripping them failed because they are not ELF files.
* Linux: Remove pread/pread64, pwrite/pwrite64 kludges from <sysdep.h>Florian Weimer2020-01-024-40/+0
| | | | | | Since the switch away from auto-generated wrappers for these system calls, the kludge is already included in the C source file of the system call wrapper.
* build-many-glibcs.py: Implement update-syscalls commandFlorian Weimer2020-01-021-3/+62
| | | | | | | | | This command uses pre-built compilers to re-install the Linux headers from the current sources into a temporary location and runs glibc's “make update-syscalls-lists” against that. This updates the glibc source tree with the current system call numbers. Reviewed-by: Siddhesh Poyarekar <siddhesh@sourceware.org>
* build-many-glibcs.py: Introduce glibc build policy classesFlorian Weimer2020-01-021-49/+80
| | | | | | | | The new classes GlibcPolicyForCompiler and GlibcPolicyForBuild allow customization of the Glibc.build_glibc method, replacing the existing for_compiler flag. Reviewed-by: Siddhesh Poyarekar <siddhesh@sourceware.org>
* build-many-glibcs.py: Introduce LinuxHeadersPolicyForBuildFlorian Weimer2020-01-021-43/+48
| | | | | | And move install_linux_headers to the top level. Reviewed-by: Siddhesh Poyarekar <siddhesh@sourceware.org>
* Linux: Use system call tables during buildFlorian Weimer2020-01-0221-58/+46
| | | | | | | | | | | | | | | | | | | | | | | Use <arch-syscall.h> instead of <asm/unistd.h> to obtain the system call numbers. A few direct includes of <asm/unistd.h> need to be removed (if the system call numbers are already provided indirectly by <sysdep.h>) or replaced with <sys/syscall.h>. Current Linux headers for alpha define the required system call names, so most of the _NR_* hacks are no longer needed. For the 32-bit arm architecture, eliminate the INTERNAL_SYSCALL_ARM macro, now that we have regular system call names for cacheflush and set_tls. There are more such cleanup opportunities for other architectures, but these cleanups are required to avoid macro redefinition errors during the build. For ia64, it is desirable to use <asm/break.h> directly to obtain the break number for system calls (which is not a system call number itself). This requires replacing __BREAK_SYSCALL with __IA64_BREAK_SYSCALL because the former is defined as an alias in <asm/unistd.h>, but not in <asm/break.h>. Reviewed-by: Siddhesh Poyarekar <siddhesh@sourceware.org>
* Linux: Add tables with system call numbersFlorian Weimer2020-01-0230-22/+9050
| | | | | | | | | | | | | | | | | | | | | | | | | | | The new tables are currently only used for consistency checks with the installed kernel headers and the architecture-independent system call names table. They are based on Linux 5.4. The goal is to use these architecture-specific tables to ensure that system call wrappers are available irrespective of the version of the installed kernel headers. The tables are formatted in the form of C header files so that they can be used directly in an #include directive, without external preprocessing. (External preprocessing of a plain table file would introduce cross-subdirectory dependency issues.) However, the intent is that they can still be treated as tables and can be processed by simple tools. The irregular system call names on 32-bit arm add a complication. The <fixup-asm-unistd.h> header is introduced to work around that, and the system calls are listed under regular names in the <arch-syscall.h> file. A make target, update-syscalls-list, is added to patch the glibc sources with data from the current kernel headers. Reviewed-by: Siddhesh Poyarekar <siddhesh@sourceware.org>
* Update copyright dates not handled by scripts/update-copyrights.Joseph Myers2020-01-0127-27/+27
| | | | | | | | | | | | | | | I've updated copyright dates in glibc for 2020. This is the patch for the changes not generated by scripts/update-copyrights and subsequent build / regeneration of generated files. As well as the usual annual updates, mainly dates in --version output (minus libc.texinfo which previously had to be handled manually but is now successfully updated by update-copyrights), there is a fix to sysdeps/unix/sysv/linux/powerpc/bits/termios-c_lflag.h where a typo in the copyright notice meant it failed to be updated automatically. Please remember to include 2020 in the dates for any new files added in future (which means updating any existing uncommitted patches you have that add new files to use the new copyright dates in them).
* Update copyright dates with scripts/update-copyrights.Joseph Myers2020-01-0110671-10671/+10671
|
* 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.
generated by cgit-pink 1.4.1 (git 2.36.1) at 2024-11-17 00:13:17 +0000