about summary refs log tree commit diff
path: root/manual
Commit message (Collapse)AuthorAgeFilesLines
* C2x strtol binary constant handlingJoseph Myers2023-02-161-3/+6
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | C2x adds binary integer constants starting with 0b or 0B, and supports those constants in strtol-family functions when the base passed is 0 or 2. Implement that strtol support for glibc. As discussed at <https://sourceware.org/pipermail/libc-alpha/2020-December/120414.html>, this is incompatible with previous C standard versions, in that such an input string starting with 0b or 0B was previously required to be parsed as 0 (with the rest of the string unprocessed). Thus, as proposed there, this patch adds 20 new __isoc23_* functions with appropriate header redirection support. This patch does *not* do anything about scanf %i (which will need 12 new functions per long double variant, so 12, 24 or 36 depending on the glibc configuration), instead leaving that for a future patch. The function names would remain as __isoc23_* even if C2x ends up published in 2024 rather than 2023. Making this change leads to the question of what should happen to internal uses of these functions in glibc and its tests. The header redirection (which applies for _GNU_SOURCE or any other feature test macros enabling C2x features) has the effect of redirecting internal uses but without those uses then ending up at a hidden alias (see the comment in include/stdio.h about interaction with libc_hidden_proto). It seems desirable for the default for internal uses to be the same versions used by normal code using _GNU_SOURCE, so rather than doing anything to disable that redirection, similar macro definitions to those in include/stdio.h are added to the include/ headers for the new functions. Given that the default for uses in glibc is for the redirections to apply, the next question is whether the C2x semantics are correct for all those uses. Uses with the base fixed to 10, 16 or any other value other than 0 or 2 can be ignored. I think this leaves the following internal uses to consider (an important consideration for review of this patch will be both whether this list is complete and whether my conclusions on all entries in it are correct): benchtests/bench-malloc-simple.c benchtests/bench-string.h elf/sotruss-lib.c math/libm-test-support.c nptl/perf.c nscd/nscd_conf.c nss/nss_files/files-parse.c posix/tst-fnmatch.c posix/wordexp.c resolv/inet_addr.c rt/tst-mqueue7.c soft-fp/testit.c stdlib/fmtmsg.c support/support_test_main.c support/test-container.c sysdeps/pthread/tst-mutex10.c I think all of these places are OK with the new semantics, except for resolv/inet_addr.c, where the POSIX semantics of inet_addr do not allow for binary constants; thus, I changed that file (to use __strtoul_internal, whose semantics are unchanged) and added a test for this case. In the case of posix/wordexp.c I think accepting binary constants is OK since POSIX explicitly allows additional forms of shell arithmetic expressions, and in stdlib/fmtmsg.c SEV_LEVEL is not in POSIX so again I think accepting binary constants is OK. Functions such as __strtol_internal, which are only exported for compatibility with old binaries from when those were used in inline functions in headers, have unchanged semantics; the __*_l_internal versions (purely internal to libc and not exported) have a new argument to specify whether to accept binary constants. As well as for the standard functions, the header redirection also applies to the *_l versions (GNU extensions), and to legacy functions such as strtoq, to avoid confusing inconsistency (the *q functions redirect to __isoc23_*ll rather than needing their own __isoc23_* entry points). For the functions that are only declared with _GNU_SOURCE, this means the old versions are no longer available for normal user programs at all. An internal __GLIBC_USE_C2X_STRTOL macro is used to control the redirections in the headers, and cases in glibc that wish to avoid the redirections - the function implementations themselves and the tests of the old versions of the GNU functions - then undefine and redefine that macro to allow the old versions to be accessed. (There would of course be greater complexity should we wish to make any of the old versions into compat symbols / avoid them being defined at all for new glibc ABIs.) strtol_l.c has some similarity to strtol.c in gnulib, but has already diverged some way (and isn't listed at all at https://sourceware.org/glibc/wiki/SharedSourceFiles unlike strtoll.c and strtoul.c); I haven't made any attempts at gnulib compatibility in the changes to that file. I note incidentally that inttypes.h and wchar.h are missing the __nonnull present on declarations of this family of functions in stdlib.h; I didn't make any changes in that regard for the new declarations added.
* S390: Influence hwcaps/stfle via GLIBC_TUNABLES.Stefan Liebler2023-02-071-1/+5
| | | | | | | | | | | | | | | | | | | | | | | | | | | This patch enables the option to influence hwcaps and stfle bits used by the s390 specific ifunc-resolvers. The currently x86-specific tunable glibc.cpu.hwcaps is also used on s390x to achieve the task. In addition the user can also set a CPU arch-level like z13 instead of single HWCAP and STFLE features. Note that the tunable only handles the features which are really used in the IFUNC-resolvers. All others are ignored as the values are only used inside glibc. Thus we can influence: - HWCAP_S390_VXRS (z13) - HWCAP_S390_VXRS_EXT (z14) - HWCAP_S390_VXRS_EXT2 (z15) - STFLE_MIE3 (z15) The influenced hwcap/stfle-bits are stored in the s390-specific cpu_features struct which also contains reserved fields for future usage. The ifunc-resolvers and users of stfle bits are adjusted to use the information from cpu_features struct. On 31bit, the ELF_MACHINE_IRELATIVE macro is now also defined. Otherwise the new ifunc-resolvers segfaults as they depend on the not yet processed_rtld_global_ro@GLIBC_PRIVATE relocation.
* Replace rawmemchr (s, '\0') with strchrWilco Dijkstra2023-02-061-9/+1
| | | | | | | | | Almost all uses of rawmemchr find the end of a string. Since most targets use a generic implementation, replacing it with strchr is better since that is optimized by compilers into strlen (s) + s. Also fix the generic rawmemchr implementation to use a cast to unsigned char in the if statement. Reviewed-by: Adhemerval Zanella <adhemerval.zanella@linaro.org>
* Update install.texi, and regenerate INSTALL.Carlos O'Donell2023-01-311-8/+8
|
* Update manual/contrib.texi.Carlos O'Donell2023-01-311-4/+12
| | | | | | | | | | | | Thank Yinyu Cai for their maintainership of the LoongArch port. Thank Vineet Gupta for their maintainership of the ARC port. Thank Tulio Magno Quites Machado Filho for their past maintainership of the PowerPC port. Thank Rajalakshmi Srinivasaraghavan for their current maintainership of the PowerPC port.
* Document '%F' format specifierPaul Pluzhnikov2023-01-251-11/+12
| | | | | | | | | | The '%F' format specifier was implemented in commit 6c46718f9f0 on 2000-08-23, but remains undocumented in the manual. https://stackoverflow.com/questions/75157669/format-specifier-f-missing-from-glibcs-documentation Fix that. Reviewed-by: Siddhesh Poyarekar <siddhesh@sourceware.org>
* manual: Fix typoMartin Joerg2023-01-181-1/+1
| | | | Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org>
* Add _FORTIFY_SOURCE implementation documentation [BZ #28998]Siddhesh Poyarekar2023-01-102-0/+251
| | | | | | | | | | | | There have been multiple requests to provide more detail on how the _FORTIFY_SOURCE macro works, so this patch adds a new node in the Library Maintenance section that does this. A lot of the description is implementation detail, which is why I put this in the appendix and not in the main documentation. Resolves: BZ #28998. Signed-off-by: Siddhesh Poyarekar <siddhesh@sourceware.org> Reviewed-by: Florian Weimer <fweimer@redhat.com>
* Update copyright dates with scripts/update-copyrightsJoseph Myers2023-01-0648-48/+48
|
* libio: Convert __vswprintf_internal to buffers (bug 27857)Florian Weimer2022-12-191-3/+4
| | | | | | | Always null-terminate the buffer and set E2BIG if the buffer is too small. This fixes bug 27857. Reviewed-by: Adhemerval Zanella <adhemerval.zanella@linaro.org>
* manual: Add missing % in int conversion listJakub Wilk2022-10-251-1/+1
| | | | Signed-off-by: Jakub Wilk <jwilk@jwilk.net>
* Use atomic_exchange_release/acquireWilco Dijkstra2022-09-262-4/+4
| | | | | | | Rename atomic_exchange_rel/acq to use atomic_exchange_release/acquire since these map to the standard C11 atomic builtins. Reviewed-by: Adhemerval Zanella <adhemerval.zanella@linaro.org>
* Use C11 atomics instead of atomic_decrement_and_testWilco Dijkstra2022-09-231-1/+1
| | | | | | | | | | Replace atomic_decrement_and_test with atomic_fetch_add_relaxed. These are simple counters which do not protect any shared data from concurrent accesses. Also remove the unused file cond-perf.c. Passes regress on AArch64. Reviewed-by: Adhemerval Zanella <adhemerval.zanella@linaro.org>
* Use C11 atomics instead of atomic_increment(_val)Wilco Dijkstra2022-09-232-3/+3
| | | | | | | | | | | Replace atomic_increment and atomic_increment_val with atomic_fetch_add_relaxed. One case in sem_post.c uses release semantics (see comment above it). The others are simple counters and do not protect any shared data from concurrent accesses. Passes regress on AArch64. Reviewed-by: Adhemerval Zanella <adhemerval.zanella@linaro.org>
* Fix BRE typos in check-safety.shPaul Eggert2022-09-141-3/+3
| | | | | * manual/check-safety.sh: Fix BRE portability typos. POSIX says \] produces undefined results.
* Use C11 atomics instead of atomic_decrement(_val)Wilco Dijkstra2022-09-092-2/+2
| | | | | | | Replace atomic_decrement and atomic_decrement_val with atomic_fetch_add_relaxed. Reviewed-by: DJ Delorie <dj@redhat.com>
* Revert "Detect ld.so and libc.so version inconsistency during startup"Florian Weimer2022-08-251-9/+0
| | | | | | | | | | | | | | | | This reverts commit 6f85dbf102ad7982409ba0fe96886caeb6389fef. Once this change hits the release branches, it will require relinking of all statically linked applications before static dlopen works again, for the majority of updates on release branches: The NEWS file is regularly updated with bug references, so the __libc_early_init suffix changes, and static dlopen cannot find the function anymore. While this ABI check is still technically correct (we do require rebuilding & relinking after glibc updates to keep static dlopen working), it is too drastic for stable release branches. Reviewed-by: Adhemerval Zanella <adhemerval.zanella@linaro.org>
* Detect ld.so and libc.so version inconsistency during startupFlorian Weimer2022-08-241-0/+9
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The files NEWS, include/link.h, and sysdeps/generic/ldsodefs.h contribute to the version fingerprint used for detection. The fingerprint can be further refined using the --with-extra-version-id configure argument. _dl_call_libc_early_init is replaced with _dl_lookup_libc_early_init. The new function is used store a pointer to libc.so's __libc_early_init function in the libc_map_early_init member of the ld.so namespace structure. This function pointer can then be called directly, so the separate invocation function is no longer needed. The versioned symbol lookup needs the symbol versioning data structures, so the initialization of libc_map and libc_map_early_init is now done from _dl_check_map_versions, after this information becomes available. (_dl_map_object_from_fd does not set this up in time, so the initialization code had to be moved from there.) This means that the separate initialization code can be removed from dl_main because _dl_check_map_versions covers all maps, including the initial executable loaded by the kernel. The lookup still happens before relocation and the invocation of IFUNC resolvers, so IFUNC resolvers are protected from ABI mismatch. The __libc_early_init function pointer is not protected because so little code runs between the pointer write and the invocation (only dynamic linker code and IFUNC resolvers). Reviewed-by: Carlos O'Donell <carlos@redhat.com>
* malloc: Correct the documentation of the top_pad defaultFlorian Weimer2022-08-041-1/+1
| | | | | DEFAULT_TOP_PAD is defined as 131072 in sysdeps/generic/malloc-machine.h.
* Update install.texi, and regenerate INSTALL.Carlos O'Donell2022-07-291-6/+6
|
* arc4random: simplify design for better safetyJason A. Donenfeld2022-07-271-10/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Rather than buffering 16 MiB of entropy in userspace (by way of chacha20), simply call getrandom() every time. This approach is doubtlessly slower, for now, but trying to prematurely optimize arc4random appears to be leading toward all sorts of nasty properties and gotchas. Instead, this patch takes a much more conservative approach. The interface is added as a basic loop wrapper around getrandom(), and then later, the kernel and libc together can work together on optimizing that. This prevents numerous issues in which userspace is unaware of when it really must throw away its buffer, since we avoid buffering all together. Future improvements may include userspace learning more from the kernel about when to do that, which might make these sorts of chacha20-based optimizations more possible. The current heuristic of 16 MiB is meaningless garbage that doesn't correspond to anything the kernel might know about. So for now, let's just do something conservative that we know is correct and won't lead to cryptographic issues for users of this function. This patch might be considered along the lines of, "optimization is the root of all evil," in that the much more complex implementation it replaces moves too fast without considering security implications, whereas the incremental approach done here is a much safer way of going about things. Once this lands, we can take our time in optimizing this properly using new interplay between the kernel and userspace. getrandom(0) is used, since that's the one that ensures the bytes returned are cryptographically secure. But on systems without it, we fallback to using /dev/urandom. This is unfortunate because it means opening a file descriptor, but there's not much of a choice. Secondly, as part of the fallback, in order to get more or less the same properties of getrandom(0), we poll on /dev/random, and if the poll succeeds at least once, then we assume the RNG is initialized. This is a rough approximation, as the ancient "non-blocking pool" initialized after the "blocking pool", not before, and it may not port back to all ancient kernels, though it does to all kernels supported by glibc (≥3.2), so generally it's the best approximation we can do. The motivation for including arc4random, in the first place, is to have source-level compatibility with existing code. That means this patch doesn't attempt to litigate the interface itself. It does, however, choose a conservative approach for implementing it. Cc: Adhemerval Zanella Netto <adhemerval.zanella@linaro.org> Cc: Florian Weimer <fweimer@redhat.com> Cc: Cristian Rodríguez <crrodriguez@opensuse.org> Cc: Paul Eggert <eggert@cs.ucla.edu> Cc: Mark Harris <mark.hsj@gmail.com> Cc: Eric Biggers <ebiggers@kernel.org> Cc: linux-crypto@vger.kernel.org Signed-off-by: Jason A. Donenfeld <Jason@zx2c4.com> Reviewed-by: Adhemerval Zanella <adhemerval.zanella@linaro.org>
* LoongArch: Update NEWS and README for the LoongArch port.caiyinyu2022-07-261-1/+1
|
* manual: Add documentation for arc4random functionsAdhemerval Zanella Netto2022-07-221-0/+46
|
* AArch64: Add asymmetric faulting mode for tag violations in mem.tagging tunableTejas Belagod2022-06-301-0/+3
| | | | | | | | | The new asymmetric mode is available when HWCAP2_MTE3 is set (support is available), bit2 is set in the tunable (user request per application), and the system is configured such that the asymmetric mode is preferred over sync or async (per-cpu system-wide setting). Reviewed-by: Szabolcs Nagy <szabolcs.nagy@arm.com>
* x86: Add bounds `x86_non_temporal_threshold`Noah Goldstein2022-06-151-1/+1
| | | | | | | | | | | | | | | The lower-bound (16448) and upper-bound (SIZE_MAX / 16) are assumed by memmove-vec-unaligned-erms. The lower-bound is needed because memmove-vec-unaligned-erms unrolls the loop aggressively in the L(large_memset_4x) case. The upper-bound is needed because memmove-vec-unaligned-erms right-shifts the value of `x86_non_temporal_threshold` by LOG_4X_MEMCPY_THRESH (4) which without a bound may overflow. The lack of lower-bound can be a correctness issue. The lack of upper-bound cannot.
* grep: egrep -> grep -E, fgrep -> grep -FSam James2022-06-051-1/+1
| | | | | | | | | | | Newer versions of GNU grep (after grep 3.7, not inclusive) will warn on 'egrep' and 'fgrep' invocations. Convert usages within the tree to their expanded non-aliased counterparts to avoid irritating warnings during ./configure and the test suite. Signed-off-by: Sam James <sam@gentoo.org> Reviewed-by: Fangrui Song <maskray@google.com>
* manual: fix reference to source fileAndreas Schwab2022-05-311-1/+1
|
* wcrtomb: Make behavior POSIX compliantSiddhesh Poyarekar2022-05-131-5/+6
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The GNU implementation of wcrtomb assumes that there are at least MB_CUR_MAX bytes available in the destination buffer passed to wcrtomb as the first argument. This is not compatible with the POSIX definition, which only requires enough space for the input wide character. This does not break much in practice because when users supply buffers smaller than MB_CUR_MAX (e.g. in ncurses), they compute and dynamically allocate the buffer, which results in enough spare space (thanks to usable_size in malloc and padding in alloca) that no actual buffer overflow occurs. However when the code is built with _FORTIFY_SOURCE, it runs into the hard check against MB_CUR_MAX in __wcrtomb_chk and hence fails. It wasn't evident until now since dynamic allocations would result in wcrtomb not being fortified but since _FORTIFY_SOURCE=3, that limitation is gone, resulting in such code failing. To fix this problem, introduce an internal buffer that is MB_LEN_MAX long and use that to perform the conversion and then copy the resultant bytes into the destination buffer. Also move the fortification check into the main implementation, which checks the result after conversion and aborts if the resultant byte count is greater than the destination buffer size. One complication is that applications that assume the MB_CUR_MAX limitation to be gone may not be able to run safely on older glibcs if they use static destination buffers smaller than MB_CUR_MAX; dynamic allocations will always have enough spare space that no actual overruns will occur. One alternative to fixing this is to bump symbol version to prevent them from running on older glibcs but that seems too strict a constraint. Instead, since these users will only have made this decision on reading the manual, I have put a note in the manual warning them about the pitfalls of having static buffers smaller than MB_CUR_MAX and running them on older glibc. Benchmarking: The wcrtomb microbenchmark shows significant increases in maximum execution time for all locales, ranging from 10x for ar_SA.UTF-8 to 1.5x-2x for nearly everything else. The mean execution time however saw practically no impact, with some results even being quicker, indicating that cache locality has a much bigger role in the overhead. Given that the additional copy uses a temporary buffer inside wcrtomb, it's likely that a hot path will end up putting that buffer (which is responsible for the additional overhead) in a similar place on stack, giving the necessary cache locality to negate the overhead. However in situations where wcrtomb ends up getting called at wildly different spots on the call stack (or is on different call stacks, e.g. with threads or different execution contexts) and is still a hotspot, the performance lag will be visible. Signed-off-by: Siddhesh Poyarekar <siddhesh@sourceware.org>
* manual: Clarify that abbreviations of long options are allowedSiddhesh Poyarekar2022-05-041-1/+2
| | | | | | | | | | The man page and code comments clearly state that abbreviations of long option names are recognized correctly as long as they are unique. Document this fact in the glibc manual as well. Signed-off-by: Siddhesh Poyarekar <siddhesh@sourceware.org> Reviewed-by: Florian Weimer <fweimer@redhat.com> Reviewed-by: Andreas Schwab <schwab@linux-m68k.org>
* dlfcn: Implement the RTLD_DI_PHDR request type for dlinfoFlorian Weimer2022-04-291-3/+12
| | | | | | | | | The information is theoretically available via dl_iterate_phdr as well, but that approach is very slow if there are many shared objects. Reviewed-by: Carlos O'Donell <carlos@redhat.com> Tested-by: Carlos O'Donell <carlos@rehdat.com>
* manual: Document the dlinfo functionFlorian Weimer2022-04-291-1/+70
| | | | | Reviewed-by: Carlos O'Donell <carlos@redhat.com> Tested-by: Carlos O'Donell <carlos@rehdat.com>
* INSTALL: Rephrase -with-default-link documentationFlorian Weimer2022-04-261-5/+5
| | | | Reviewed-by: Carlos O'Donell <carlos@redhat.com>
* Default to --with-default-link=no (bug 25812)Florian Weimer2022-04-221-0/+6
| | | | | | | | | This is necessary to place the libio vtables into the RELRO segment. New tests elf/tst-relro-ldso and elf/tst-relro-libc are added to verify that this is what actually happens. The new tests fail on ia64 due to lack of (default) RELRO support inbutils, so they are XFAILed there.
* nptl: Handle spurious EINTR when thread cancellation is disabled (BZ#29029)Adhemerval Zanella2022-04-141-2/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Some Linux interfaces never restart after being interrupted by a signal handler, regardless of the use of SA_RESTART [1]. It means that for pthread cancellation, if the target thread disables cancellation with pthread_setcancelstate and calls such interfaces (like poll or select), it should not see spurious EINTR failures due the internal SIGCANCEL. However recent changes made pthread_cancel to always sent the internal signal, regardless of the target thread cancellation status or type. To fix it, the previous semantic is restored, where the cancel signal is only sent if the target thread has cancelation enabled in asynchronous mode. The cancel state and cancel type is moved back to cancelhandling and atomic operation are used to synchronize between threads. The patch essentially revert the following commits: 8c1c0aae20 nptl: Move cancel type out of cancelhandling 2b51742531 nptl: Move cancel state out of cancelhandling 26cfbb7162 nptl: Remove CANCELING_BITMASK However I changed the atomic operation to follow the internal C11 semantic and removed the MACRO usage, it simplifies a bit the resulting code (and removes another usage of the old atomic macros). Checked on x86_64-linux-gnu, i686-linux-gnu, aarch64-linux-gnu, and powerpc64-linux-gnu. [1] https://man7.org/linux/man-pages/man7/signal.7.html Reviewed-by: Florian Weimer <fweimer@redhat.com> Tested-by: Aurelien Jarno <aurelien@aurel32.net>
* hurd: Define ELIBEXECSamuel Thibault2022-04-121-5/+5
| | | | So we can implement it in the exec server.
* manual: SA_ONSTACK is ignored without alternate stackFlorian Weimer2022-02-281-1/+1
| | | | The current stack is used. No SIGILL is generated.
* Update install.texi, and regenerate INSTALL.Carlos O'Donell2022-02-031-9/+12
|
* Linux: Use ptrdiff_t for __rseq_offsetFlorian Weimer2022-02-021-1/+1
| | | | | | | | This matches the data size initial-exec relocations use on most targets. Reviewed-by: Mathieu Desnoyers <mathieu.desnoyers@efficios.com> Reviewed-by: Carlos O'Donell <carlos@redhat.com>
* x86_64: Document libmvec vector functions accuracy [BZ #28766]Sunil K Pandey2022-01-191-2/+3
| | | | | | | Document maximum 4 ulps accuracy for x86_64 libmvec functions. This fixes BZ #28766. Reviewed-By: Paul Zimmermann <Paul.Zimmermann@inria.fr>
* Add --with-rtld-early-cflags configure optionFlorian Weimer2022-01-141-0/+7
| | | | | Reviewed-by: H.J. Lu <hjl.tools@gmail.com> Reviewed-by: Carlos O'Donell <carlos@redhat.com>
* manual: Drop obsolete @refillSiddhesh Poyarekar2022-01-1210-21/+21
| | | | | | | | The @refill command has been obsolete for a while and now texinfo has started warning about it. Reviewed-by: Florian Weimer <fweimer@redhat.com> Signed-off-by: Siddhesh Poyarekar <siddhesh@sourceware.org>
* math: Fix float conversion regressions with gcc-12 [BZ #28713]Szabolcs Nagy2022-01-101-3/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Converting double precision constants to float is now affected by the runtime dynamic rounding mode instead of being evaluated at compile time with default rounding mode (except static object initializers). This can change the computed result and cause performance regression. The known correctness issues (increased ulp errors) are already fixed, this patch fixes remaining cases of unnecessary runtime conversions. Add float M_* macros to math.h as new GNU extension API. To avoid conversions the new M_* macros are used and instead of casting double literals to float, use float literals (only required if the conversion is inexact). The patch was tested on aarch64 where the following symbols had new spurious conversion instructions that got fixed: __clog10f __gammaf_r_finite@GLIBC_2.17 __j0f_finite@GLIBC_2.17 __j1f_finite@GLIBC_2.17 __jnf_finite@GLIBC_2.17 __kernel_casinhf __lgamma_negf __log1pf __y0f_finite@GLIBC_2.17 __y1f_finite@GLIBC_2.17 cacosf cacoshf casinhf catanf catanhf clogf gammaf_positive Fixes bug 28713. Reviewed-by: Paul Zimmermann <Paul.Zimmermann@inria.fr>
* Update copyright dates with scripts/update-copyrightsPaul Eggert2022-01-0148-48/+48
| | | | | | | | | | | | | | | | | | | | | | | I used these shell commands: ../glibc/scripts/update-copyrights $PWD/../gnulib/build-aux/update-copyright (cd ../glibc && git commit -am"[this commit message]") and then ignored the output, which consisted lines saying "FOO: warning: copyright statement not found" for each of 7061 files FOO. I then removed trailing white space from math/tgmath.h, support/tst-support-open-dev-null-range.c, and sysdeps/x86_64/multiarch/strlen-vec.S, to work around the following obscure pre-commit check failure diagnostics from Savannah. I don't know why I run into these diagnostics whereas others evidently do not. remote: *** 912-#endif remote: *** 913: remote: *** 914- remote: *** error: lines with trailing whitespace found ... remote: *** error: sysdeps/unix/sysv/linux/statx_cp.c: trailing lines
* elf: Add _dl_find_object functionFlorian Weimer2021-12-285-13/+140
| | | | | | | | | | | | | | | | | | | | | | | | | It can be used to speed up the libgcc unwinder, and the internal _dl_find_dso_for_object function (which is used for caller identification in dlopen and related functions, and in dladdr). _dl_find_object is in the internal namespace due to bug 28503. If libgcc switches to _dl_find_object, this namespace issue will be fixed. It is located in libc for two reasons: it is necessary to forward the call to the static libc after static dlopen, and there is a link ordering issue with -static-libgcc and libgcc_eh.a because libc.so is not a linker script that includes ld.so in the glibc build tree (so that GCC's internal -lc after libgcc_eh.a does not pick up ld.so). It is necessary to do the i386 customization in the sysdeps/x86/bits/dl_find_object.h header shared with x86-64 because otherwise, multilib installations are broken. The implementation uses software transactional memory, as suggested by Torvald Riegel. Two copies of the supporting data structures are used, also achieving full async-signal-safety. Reviewed-by: Adhemerval Zanella <adhemerval.zanella@linaro.org>
* stdio: Implement %#m for vfprintf and related functionsFlorian Weimer2021-12-231-2/+6
| | | | | | | | | %#m prints errno as an error constant if one is available, or a decimal number as a fallback. This intends to address the gap that strerrorname_np does not work well with printf for unknown error codes due to its NULL return values in those cases. Reviewed-by: Adhemerval Zanella <adhemerval.zanella@linaro.org>
* nss: Use "files dns" as the default for the hosts database (bug 28700)Florian Weimer2021-12-171-3/+2
| | | | | | | | | | | | | | | | | | This matches what is currently in nss/nsswitch.conf. The new ordering matches what most distributions use in their installed configuration files. It is common to add localhost to /etc/hosts because the name does not exist in the DNS, but is commonly used as a host name. With the built-in "dns [!UNAVAIL=return] files" default, dns is searched first and provides an answer for "localhost" (NXDOMAIN). We never look at the files database as a result, so the contents of /etc/hosts is ignored. This means that "getent hosts localhost" fail without a /etc/nsswitch.conf file, even though the host name is listed in /etc/hosts. Reviewed-by: Carlos O'Donell <carlos@redhat.com>
* malloc: Add Huge Page support for mmapAdhemerval Zanella2021-12-151-0/+7
| | | | | | | | | | | | | | | | | | | | | | | | | | | | With the morecore hook removed, there is not easy way to provide huge pages support on with glibc allocator without resorting to transparent huge pages. And some users and programs do prefer to use the huge pages directly instead of THP for multiple reasons: no splitting, re-merging by the VM, no TLB shootdowns for running processes, fast allocation from the reserve pool, no competition with the rest of the processes unlike THP, no swapping all, etc. This patch extends the 'glibc.malloc.hugetlb' tunable: the value '2' means to use huge pages directly with the system default size, while a positive value means and specific page size that is matched against the supported ones by the system. Currently only memory allocated on sysmalloc() is handled, the arenas still uses the default system page size. To test is a new rule is added tests-malloc-hugetlb2, which run the addes tests with the required GLIBC_TUNABLE setting. On systems without a reserved huge pages pool, is just stress the mmap(MAP_HUGETLB) allocation failure. To improve test coverage it is required to create a pool with some allocated pages. Checked on x86_64-linux-gnu. Reviewed-by: DJ Delorie <dj@redhat.com>
* malloc: Add madvise support for Transparent Huge PagesAdhemerval Zanella2021-12-151-0/+10
| | | | | | | | | | | | | | | | | | | | | | | | | | Linux Transparent Huge Pages (THP) current supports three different states: 'never', 'madvise', and 'always'. The 'never' is self-explanatory and 'always' will enable THP for all anonymous pages. However, 'madvise' is still the default for some system and for such case THP will be only used if the memory range is explicity advertise by the program through a madvise(MADV_HUGEPAGE) call. To enable it a new tunable is provided, 'glibc.malloc.hugetlb', where setting to a value diffent than 0 enables the madvise call. This patch issues the madvise(MADV_HUGEPAGE) call after a successful mmap() call at sysmalloc() with sizes larger than the default huge page size. The madvise() call is disable is system does not support THP or if it has the mode set to "never" and on Linux only support one page size for THP, even if the architecture supports multiple sizes. To test is a new rule is added tests-malloc-hugetlb1, which run the addes tests with the required GLIBC_TUNABLE setting. Checked on x86_64-linux-gnu. Reviewed-by: DJ Delorie <dj@redhat.com>
* elf: Use new dependency sorting algorithm by defaultFlorian Weimer2021-12-141-1/+1
| | | | | | | The default has to change eventually, and there are no known failures that require a delay. Reviewed-by: Adhemerval Zanella <adhemerval.zanella@linaro.org>
* Replace --enable-static-pie with --disable-default-pieSiddhesh Poyarekar2021-12-131-9/+7
| | | | | | | | | | | | | | | | | | | | | | | | Build glibc programs and tests as PIE by default and enable static-pie automatically if the architecture and toolchain supports it. Also add a new configuration option --disable-default-pie to prevent building programs as PIE. Only the following architectures now have PIE disabled by default because they do not work at the moment. hppa, ia64, alpha and csky don't work because the linker is unable to handle a pcrel relocation generated from PIE objects. The microblaze compiler is currently failing with an ICE. GNU hurd tries to enable static-pie, which does not work and hence fails. All these targets have default PIE disabled at the moment and I have left it to the target maintainers to enable PIE on their targets. build-many-glibcs runs clean for all targets. I also tested x86_64 on Fedora and Ubuntu, to verify that the default build as well as --disable-default-pie work as expected with both system toolchains. Signed-off-by: Siddhesh Poyarekar <siddhesh@sourceware.org> Reviewed-by: Adhemerval Zanella <adhemerval.zanella@linaro.org>
generated by cgit-pink 1.4.1 (git 2.36.1) at 2024-11-24 02:16:15 +0000