about summary refs log tree commit diff
path: root/NEWS
Commit message (Collapse)AuthorAgeFilesLines
...
* elf: Fix runtime linker auditing on aarch64 (BZ #26643)Ben Woodard2022-02-011-0/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The rtld audit support show two problems on aarch64: 1. _dl_runtime_resolve does not preserve x8, the indirect result location register, which might generate wrong result calls depending of the function signature. 2. The NEON Q registers pushed onto the stack by _dl_runtime_resolve were twice the size of D registers extracted from the stack frame by _dl_runtime_profile. While 2. might result in wrong information passed on the PLT tracing, 1. generates wrong runtime behaviour. The aarch64 rtld audit support is changed to: * Both La_aarch64_regs and La_aarch64_retval are expanded to include both x8 and the full sized NEON V registers, as defined by the ABI. * dl_runtime_profile needed to extract registers saved by _dl_runtime_resolve and put them into the new correctly sized La_aarch64_regs structure. * The LAV_CURRENT check is change to only accept new audit modules to avoid the undefined behavior of not save/restore x8. * Different than other architectures, audit modules older than LAV_CURRENT are rejected (both La_aarch64_regs and La_aarch64_retval changed their layout and there are no requirements to support multiple audit interface with the inherent aarch64 issues). * A new field is also reserved on both La_aarch64_regs and La_aarch64_retval to support variant pcs symbols. Similar to x86, a new La_aarch64_vector type to represent the NEON register is added on the La_aarch64_regs (so each type can be accessed directly). Since LAV_CURRENT was already bumped to support bind-now, there is no need to increase it again. Checked on aarch64-linux-gnu. Co-authored-by: Adhemerval Zanella <adhemerval.zanella@linaro.org> Reviewed-by: Szabolcs Nagy <szabolcs.nagy@arm.com> Reviewed-by: Carlos O'Donell <carlos@redhat.com> Tested-by: Carlos O'Donell <carlos@redhat.com>
* elf: Issue la_symbind for bind-now (BZ #23734)Adhemerval Zanella2022-02-011-0/+4
| | | | | | | | | | | | | | | | | | | | | | | The audit symbind callback is not called for binaries built with -Wl,-z,now or when LD_BIND_NOW=1 is used, nor the PLT tracking callbacks (plt_enter and plt_exit) since this would change the expected program semantics (where no PLT is expected) and would have performance implications (such as for BZ#15533). LAV_CURRENT is also bumped to indicate the audit ABI change (where la_symbind flags are set by the loader to indicate no possible PLT trace). To handle powerpc64 ELFv1 function descriptor, _dl_audit_symbind requires to know whether bind-now is used so the symbol value is updated to function text segment instead of the OPD (for lazy binding this is done by PPC64_LOAD_FUNCPTR on _dl_runtime_resolve). Checked on x86_64-linux-gnu, i686-linux-gnu, aarch64-linux-gnu, powerpc64-linux-gnu. Reviewed-by: Carlos O'Donell <carlos@redhat.com> Tested-by: Carlos O'Donell <carlos@redhat.com>
* Mention _FORTIFY_SOURCE=3 for gcc12 in NEWSSiddhesh Poyarekar2022-01-311-0/+6
| | | | Signed-off-by: Siddhesh Poyarekar <siddhesh@sourceware.org>
* Add prelink removal plan on NEWSAdhemerval Zanella2022-01-281-0/+4
| | | | Reviewed-by: Carlos O'Donell <carlos@redhat.com>
* posix: Add terminal control setting support for posix_spawnAdhemerval Zanella2022-01-251-0/+5
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Currently there is no proper way to set the controlling terminal through posix_spawn in race free manner [1]. This forces shell implementations to keep using fork+exec when launching background process groups, even when using posix_spawn yields better performance. This patch adds a new GNU extension so the creating process can configure the created process terminal group. This is done with a new flag, POSIX_SPAWN_TCSETPGROUP, along with two new attribute functions: posix_spawnattr_tcsetpgrp_np, and posix_spawnattr_tcgetpgrp_np. The function sets a new attribute, spawn-tcgroupfd, that references to the controlling terminal. The controlling terminal is set after the spawn-pgroup attribute, and uses the spawn-tcgroupfd along with current creating process group (so it is composable with POSIX_SPAWN_SETPGROUP). To create a process and set the controlling terminal, one can use the following sequence: posix_spawnattr_t attr; posix_spawnattr_init (&attr); posix_spawnattr_setflags (&attr, POSIX_SPAWN_TCSETPGROUP); posix_spawnattr_tcsetpgrp_np (&attr, tcfd); If the idea is also to create a new process groups: posix_spawnattr_t attr; posix_spawnattr_init (&attr); posix_spawnattr_setflags (&attr, POSIX_SPAWN_TCSETPGROUP | POSIX_SPAWN_SETPGROUP); posix_spawnattr_tcsetpgrp_np (&attr, tcfd); posix_spawnattr_setpgroup (&attr, 0); The controlling terminal file descriptor is ignored if the new flag is not set. This interface is slight different than the one provided by QNX [2], which only provides the POSIX_SPAWN_TCSETPGROUP flag. The QNX documentation does not specify how the controlling terminal is obtained nor how it iteracts with POSIX_SPAWN_SETPGROUP. Since a glibc implementation is library based, it is more straightforward and avoid requires additional file descriptor operations to request the caller to setup the controlling terminal file descriptor (and it also allows a bit less error handling by posix_spawn). Checked on x86_64-linux-gnu and i686-linux-gnu. [1] https://github.com/ksh93/ksh/issues/79 [2] https://www.qnx.com/developers/docs/7.0.0/index.html#com.qnx.doc.neutrino.lib_ref/topic/p/posix_spawn.html Reviewed-by: Carlos O'Donell <carlos@redhat.com> Tested-by: Carlos O'Donell <carlos@redhat.com>
* getcwd: Set errno to ERANGE for size == 1 (CVE-2021-3999)Siddhesh Poyarekar2022-01-241-0/+6
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | No valid path returned by getcwd would fit into 1 byte, so reject the size early and return NULL with errno set to ERANGE. This change is prompted by CVE-2021-3999, which describes a single byte buffer underflow and overflow when all of the following conditions are met: - The buffer size (i.e. the second argument of getcwd) is 1 byte - The current working directory is too long - '/' is also mounted on the current working directory Sequence of events: - In sysdeps/unix/sysv/linux/getcwd.c, the syscall returns ENAMETOOLONG because the linux kernel checks for name length before it checks buffer size - The code falls back to the generic getcwd in sysdeps/posix - In the generic func, the buf[0] is set to '\0' on line 250 - this while loop on line 262 is bypassed: while (!(thisdev == rootdev && thisino == rootino)) since the rootfs (/) is bind mounted onto the directory and the flow goes on to line 449, where it puts a '/' in the byte before the buffer. - Finally on line 458, it moves 2 bytes (the underflowed byte and the '\0') to the buf[0] and buf[1], resulting in a 1 byte buffer overflow. - buf is returned on line 469 and errno is not set. This resolves BZ #28769. Reviewed-by: Andreas Schwab <schwab@linux-m68k.org> Reviewed-by: Adhemerval Zanella <adhemerval.zanella@linaro.org> Signed-off-by: Qualys Security Advisory <qsa@qualys.com> Signed-off-by: Siddhesh Poyarekar <siddhesh@sourceware.org>
* realpath: Set errno to ENAMETOOLONG for result larger than PATH_MAX [BZ #28770]Siddhesh Poyarekar2022-01-211-0/+4
| | | | | | | | | | | | | | realpath returns an allocated string when the result exceeds PATH_MAX, which is unexpected when its second argument is not NULL. This results in the second argument (resolved) being uninitialized and also results in a memory leak since the caller expects resolved to be the same as the returned value. Return NULL and set errno to ENAMETOOLONG if the result exceeds PATH_MAX. This fixes [BZ #28770], which is CVE-2021-3998. Reviewed-by: Adhemerval Zanella <adhemerval.zanella@linaro.org> Signed-off-by: Siddhesh Poyarekar <siddhesh@sourceware.org>
* Linux: Add epoll_pwait2 (BZ #27359)Adhemerval Zanella2022-01-171-0/+3
| | | | | | | | | | | | | It is similar to epoll_wait, with the difference the timeout has nanosecond resoluting by using struct timespec instead of int. Although Linux interface only provides 64 bit time_t support, old 32 bit interface is also provided (so keep in sync with current practice and to no force opt-in on 64 bit time_t). Checked on x86_64-linux-gnu and i686-linux-gnu. Reviewed-by: Florian Weimer <fweimer@redhat.com>
* CVE-2022-23218: Buffer overflow in sunrpc svcunix_create (bug 28768)Florian Weimer2022-01-171-0/+3
| | | | | | | The sunrpc function svcunix_create suffers from a stack-based buffer overflow with overlong pathname arguments. Reviewed-by: Siddhesh Poyarekar <siddhesh@sourceware.org>
* CVE-2022-23219: Buffer overflow in sunrpc clnt_create for "unix" (bug 22542)Florian Weimer2022-01-171-1/+3
| | | | | | | Processing an overlong pathname in the sunrpc clnt_create function results in a stack-based buffer overflow. Reviewed-by: Siddhesh Poyarekar <siddhesh@sourceware.org>
* Add --with-rtld-early-cflags configure optionFlorian Weimer2022-01-141-0/+6
| | | | | Reviewed-by: H.J. Lu <hjl.tools@gmail.com> Reviewed-by: Carlos O'Donell <carlos@redhat.com>
* math: Fix float conversion regressions with gcc-12 [BZ #28713]Szabolcs Nagy2022-01-101-0/+5
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
* debug: Remove catchsegv and libSegfault (BZ #14913)Adhemerval Zanella2022-01-061-0/+4
| | | | | | | | | | | | Trapping SIGSEGV within the process is error-prone, adds security issues, and modern analysis design tends to happen out of the process (either by attaching a debugger or by post-mortem analysis). The libSegfault also has some design problems, it uses non async-signal-safe function (backtrace) on signal handler. There are multiple alternatives if users do want to use similar functionality, such as sigsegv gnulib module or libsegfault.
* Documentation for OpenRISC portStafford Horne2022-01-051-0/+9
| | | | | | | | | | | | | | | | OpenRISC architecture specification: https://raw.githubusercontent.com/openrisc/doc/master/openrisc-arch-1.3-rev1.pdf Currently the port as of the 2022-01-03 rebasing there are no known architecture specific test failures. Writing credits for the port are: Stafford Horne <shorne@gmail.com> Christian Svensson <blue@cmd.nu> Reviewed-by: Adhemerval Zanella <adhemerval.zanella@linaro.org>
* Update copyright dates with scripts/update-copyrightsPaul Eggert2022-01-011-1/+1
| | | | | | | | | | | | | | | | | | | | | | | 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-281-0/+4
| | | | | | | | | | | | | | | | | | | | | | | | | 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>
* elf: Avoid unnecessary slowdown from profiling with audit (BZ#15533)Adhemerval Zanella2021-12-281-0/+3
| | | | | | | | | | | | | | | | | | | The rtld-audit interfaces introduces a slowdown due to enabling profiling instrumentation (as if LD_AUDIT implied LD_PROFILE). However, instrumenting is only necessary if one of audit libraries provides PLT callbacks (la_pltenter or la_pltexit symbols). Otherwise, the slowdown can be avoided. The following patch adjusts the logic that enables profiling to iterate over all audit modules and check if any of those provides a PLT hook. To keep la_symbind to work even without PLT callbacks, _dl_fixup now calls the audit callback if the modules implements it. Co-authored-by: Alexander Monakov <amonakov@ispras.ru> Checked on x86_64-linux-gnu, i686-linux-gnu, and aarch64-linux-gnu. Reviewed-by: Florian Weimer <fweimer@redhat.com>
* stdio: Implement %#m for vfprintf and related functionsFlorian Weimer2021-12-231-0/+3
| | | | | | | | | %#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>
* malloc: Add Huge Page support for mmapAdhemerval Zanella2021-12-151-3/+5
| | | | | | | | | | | | | | | | | | | | | | | | | | | | 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/+5
| | | | | | | | | | | | | | | | | | | | | | | | | | 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>
* NEWS: Document LD_PREFER_MAP_32BIT_EXEC as x86-64 onlyH.J. Lu2021-12-141-3/+3
|
* elf: Use new dependency sorting algorithm by defaultFlorian Weimer2021-12-141-3/+4
| | | | | | | The default has to change eventually, and there are no known failures that require a delay. Reviewed-by: Adhemerval Zanella <adhemerval.zanella@linaro.org>
* NEWS: Move LD_PREFER_MAP_32BIT_EXECH.J. Lu2021-12-131-4/+4
| | | | | | Move LD_PREFER_MAP_32BIT_EXEC to Deprecated and removed features, and other changes affecting compatibility:
* Replace --enable-static-pie with --disable-default-pieSiddhesh Poyarekar2021-12-131-0/+13
| | | | | | | | | | | | | | | | | | | | | | | | 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>
* x86-64: Remove LD_PREFER_MAP_32BIT_EXEC support [BZ #28656]H.J. Lu2021-12-101-0/+4
| | | | | | | | | | Remove the LD_PREFER_MAP_32BIT_EXEC environment variable support since the first PT_LOAD segment is no longer executable due to defaulting to -z separate-code. This fixes [BZ #28656]. Reviewed-by: Florian Weimer <fweimer@redhat.com>
* elf: Install a symbolic link to ld.so as /usr/bin/ld.soFlorian Weimer2021-12-101-0/+3
| | | | | | | | This makes ld.so features such as --preload, --audit, and --list-diagnostics more accessible to end users because they do not need to know the ABI name of the dynamic loader. Reviewed-by: Carlos O'Donell <carlos@redhat.com>
* nptl: Add public rseq symbols and <sys/rseq.h>Florian Weimer2021-12-091-0/+11
| | | | | | | | | | | | | The relationship between the thread pointer and the rseq area is made explicit. The constant offset can be used by JIT compilers to optimize rseq access (e.g., for really fast sched_getcpu). Extensibility is provided through __rseq_size and __rseq_flags. (In the future, the kernel could request a different rseq size via the auxiliary vector.) Co-Authored-By: Mathieu Desnoyers <mathieu.desnoyers@efficios.com> Reviewed-by: Szabolcs Nagy <szabolcs.nagy@arm.com>
* elf: execve statically linked programs instead of crashing [BZ #28648]Florian Weimer2021-12-051-0/+4
| | | | | | | | | | | | | | | Programs without dynamic dependencies and without a program interpreter are now run via execve. Previously, the dynamic linker either crashed while attempting to read a non-existing dynamic segment (looking for DT_AUDIT/DT_DEPAUDIT data), or the self-relocated in the static PIE executable crashed because the outer dynamic linker had already applied RELRO protection. <dl-execve.h> is needed because execve is not available in the dynamic loader on Hurd. Reviewed-by: H.J. Lu <hjl.tools@gmail.com>
* Support C2X printf %b, %BJoseph Myers2021-11-101-0/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | C2X adds a printf %b format (see <http://www.open-std.org/jtc1/sc22/wg14/www/docs/n2630.pdf>, accepted for C2X), for outputting integers in binary. It also has recommended practice for a corresponding %B format (like %b, but %#B starts the output with 0B instead of 0b). Add support for these formats to glibc. One existing test uses %b as an example of an unknown format, to test how glibc printf handles unknown formats; change that to %v. Use of %b and %B as user-registered format specifiers continues to work (and we already have a test that covers that, tst-printfsz.c). Note that C2X also has scanf %b support, plus support for binary constants starting 0b in strtol (base 0 and 2) and scanf %i (strtol base 0 and scanf %i coming from a previous paper that added binary integer literals). I intend to implement those features in a separate patch or patches; as discussed in the thread starting at <https://sourceware.org/pipermail/libc-alpha/2020-December/120414.html>, they will be more complicated because they involve adding extra public symbols to ensure compatibility with existing code that might not expect 0b constants to be handled by strtol base 0 and 2 and scanf %i, whereas simply adding a new format specifier poses no such compatibility concerns. Note that the actual conversion from integer to string uses existing code in _itoa.c. That code has special cases for bases 8, 10 and 16, probably so that the compiler can optimize division by an integer constant in the code for those bases. If desired such special cases could easily be added for base 2 as well, but that would be an optimization, not actually needed for these printf formats to work. Tested for x86_64 and x86. Also tested with build-many-glibcs.py for aarch64-linux-gnu with GCC mainline to make sure that the test does indeed build with GCC 12 (where format checking warnings are enabled for most of the test).
* NEWS: Add item for __memcmpeqNoah Goldstein2021-10-261-0/+4
|
* elf: Fix slow DSO sorting behavior in dynamic loader (BZ #17645)Chung-Lin Tang2021-10-211-0/+9
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This second patch contains the actual implementation of a new sorting algorithm for shared objects in the dynamic loader, which solves the slow behavior that the current "old" algorithm falls into when the DSO set contains circular dependencies. The new algorithm implemented here is simply depth-first search (DFS) to obtain the Reverse-Post Order (RPO) sequence, a topological sort. A new l_visited:1 bitfield is added to struct link_map to more elegantly facilitate such a search. The DFS algorithm is applied to the input maps[nmap-1] backwards towards maps[0]. This has the effect of a more "shallow" recursion depth in general since the input is in BFS. Also, when combined with the natural order of processing l_initfini[] at each node, this creates a resulting output sorting closer to the intuitive "left-to-right" order in most cases. Another notable implementation adjustment related to this _dl_sort_maps change is the removing of two char arrays 'used' and 'done' in _dl_close_worker to represent two per-map attributes. This has been changed to simply use two new bit-fields l_map_used:1, l_map_done:1 added to struct link_map. This also allows discarding the clunky 'used' array sorting that _dl_sort_maps had to sometimes do along the way. Tunable support for switching between different sorting algorithms at runtime is also added. A new tunable 'glibc.rtld.dynamic_sort' with current valid values 1 (old algorithm) and 2 (new DFS algorithm) has been added. At time of commit of this patch, the default setting is 1 (old algorithm). Signed-off-by: Chung-Lin Tang <cltang@codesourcery.com> Reviewed-by: Adhemerval Zanella <adhemerval.zanella@linaro.org>
* elf: Remove Intel MPX support (lazy PLT, ld.so profile, and LD_AUDIT)Fangrui Song2021-10-111-0/+2
| | | | | | | | | | Intel MPX failed to gain wide adoption and has been deprecated for a while. GCC 9.1 removed Intel MPX support. Linux kernel removed MPX in 2019. This patch removes the support code from the dynamic loader. Reviewed-by: H.J. Lu <hjl.tools@gmail.com>
* Update to Unicode 14.0.0 [BZ #28390]Mike FABIAN2021-10-041-0/+4
| | | | | | | | | | | | | | | Unicode 14.0.0 Support: Character encoding, character type info, and transliteration tables are all updated to Unicode 14.0.0, using the generator scripts contributed by Mike FABIAN (Red Hat). Total added characters in newly generated CHARMAP: 838 Total removed characters in newly generated WIDTH: 1 (Characters not in WIDTH get width 1 by default, i.e. these have width 1 now.) removed: <U1734> 0 : eaw=N category=Mc bidi=L name=HANUNOO SIGN PAMUDPOD That seems intentional, the character had category Mn (Mark, nonspacing) before and now has Mc (Mark, spacing combining) Total changed characters in newly generated WIDTH: 0 Total added characters in newly generated WIDTH: 175
* Add C2X _PRINTF_NAN_LEN_MAXJoseph Myers2021-09-301-0/+2
| | | | | | | | | | | | | | C2X adds a macro _PRINTF_NAN_LEN_MAX to <stdio.h>, giving the maximum length of printf output for a NaN. glibc never includes an n-char-sequence in its printf output for NaNs, so the correct value for glibc is 4 ("-nan" or "-NAN"); define the macro accordingly. This patch makes the macro definition conditional on __GLIBC_USE (ISOC2X), as is generally done with features from new standard versions. The name is in the implementation namespace for older standards, so it would also be possible to define it unconditionally. Tested for x86_64.
* Add exp10 macro to <tgmath.h> (bug 26108)Joseph Myers2021-09-301-0/+3
| | | | | | | | | | | | | glibc has had exp10 functions since long before they were standardized; now they are standardized in TS 18661-4 and C2X, they are also specified there to have a corresponding type-generic macro. Add one to <tgmath.h>, so fixing bug 26108. glibc doesn't have other functions from TS 18661-4 yet, but when added, it will be natural to add the type-generic macro for each function family at the same time as the functions. Tested for x86_64.
* Add fmaximum, fminimum functionsJoseph Myers2021-09-281-0/+7
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | C2X adds new <math.h> functions for floating-point maximum and minimum, corresponding to the new operations that were added in IEEE 754-2019 because of concerns about the old operations not being associative in the presence of signaling NaNs. fmaximum and fminimum handle NaNs like most <math.h> functions (any NaN argument means the result is a quiet NaN). fmaximum_num and fminimum_num handle both quiet and signaling NaNs the way fmax and fmin handle quiet NaNs (if one argument is a number and the other is a NaN, return the number), but still raise "invalid" for a signaling NaN argument, making them exceptions to the normal rule that a function with a floating-point result raising "invalid" also returns a quiet NaN. fmaximum_mag, fminimum_mag, fmaximum_mag_num and fminimum_mag_num are corresponding functions returning the argument with greatest or least absolute value. All these functions also treat +0 as greater than -0. There are also corresponding <tgmath.h> type-generic macros. Add these functions to glibc. The implementations use type-generic templates based on those for fmax, fmin, fmaxmag and fminmag, and test inputs are based on those for those functions with appropriate adjustments to the expected results. The RISC-V maintainers might wish to add optimized versions of fmaximum_num and fminimum_num (for float and double), since RISC-V (F extension version 2.2 and later) provides instructions corresponding to those functions - though it might be at least as useful to add architecture-independent built-in functions to GCC and teach the RISC-V back end to expand those functions inline, which is what you generally want for functions that can be implemented with a single instruction. Tested for x86_64 and x86, and with build-many-glibcs.py.
* Define __STDC_IEC_60559_BFP__ and __STDC_IEC_60559_COMPLEX__Joseph Myers2021-09-241-0/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | TS 18661-1 and C2X specify predefined macros __STDC_IEC_60559_BFP__ and __STDC_IEC_60559_COMPLEX__, making __STDC_IEC_559__ and __STDC_IEC_559_COMPLEX__ obsolescent (but still included in the standard). Now that we have all the functions from TS 18661-1, define these macros in stdc-predef.h, under the same conditions in which the older macros are defined, since support for the floating-point features in TS 18661-1 is now at the same level as that for those in C11 and before (all library functions and other library APIs present, but no standard pragma support). The macros are defined for now with their TS 18661-1 values. C2X will give them new values (listed as yyyymmL in the working drafts until the final standard), at which point there will be the question of what value to use in stdc-predef.h (where it could depend on __STDC_VERSION__, but not on feature test macros defined by the user). My inclination then would be to use the C2X value unconditionally rather than using an older value to indicate TS support, and only have any C standard version conditionals for the value when subsequent C standard versions define further values. (Note that I'm also inclined, when we implement the C2X change to the return types of fromfp functions, to make that change unconditional much like the change made to the types of totalorder functions, with the old version only supported with compat symbols for already-linked programs and not as an API for newly built objects. So using the C2X value would also accurately reflect not supporting the versions of APIs in the TS where those ended up being incompatible with the first version actually added to the standard.) Tested for x86_64.
* Add narrowing fma functionsJoseph Myers2021-09-221-0/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This patch adds the narrowing fused multiply-add functions from TS 18661-1 / TS 18661-3 / C2X to glibc's libm: ffma, ffmal, dfmal, f32fmaf64, f32fmaf32x, f32xfmaf64 for all configurations; f32fmaf64x, f32fmaf128, f64fmaf64x, f64fmaf128, f32xfmaf64x, f32xfmaf128, f64xfmaf128 for configurations with _Float64x and _Float128; __f32fmaieee128 and __f64fmaieee128 aliases in the powerpc64le case (for calls to ffmal and dfmal when long double is IEEE binary128). Corresponding tgmath.h macro support is also added. The changes are mostly similar to those for the other narrowing functions previously added, especially that for sqrt, so the description of those generally applies to this patch as well. As with sqrt, I reused the same test inputs in auto-libm-test-in as for non-narrowing fma rather than adding extra or separate inputs for narrowing fma. The tests in libm-test-narrow-fma.inc also follow those for non-narrowing fma. The non-narrowing fma has a known bug (bug 6801) that it does not set errno on errors (overflow, underflow, Inf * 0, Inf - Inf). Rather than fixing this or having narrowing fma check for errors when non-narrowing does not (complicating the cases when narrowing fma can otherwise be an alias for a non-narrowing function), this patch does not attempt to check for errors from narrowing fma and set errno; the CHECK_NARROW_FMA macro is still present, but as a placeholder that does nothing, and this missing errno setting is considered to be covered by the existing bug rather than needing a separate open bug. missing-errno annotations are duly added to many of the auto-libm-test-in test inputs for fma. This completes adding all the new functions from TS 18661-1 to glibc, so will be followed by corresponding stdc-predef.h changes to define __STDC_IEC_60559_BFP__ and __STDC_IEC_60559_COMPLEX__, as the support for TS 18661-1 will be at a similar level to that for C standard floating-point facilities up to C11 (pragmas not implemented, but library functions done). (There are still further changes to be done to implement changes to the types of fromfp functions from N2548.) Tested as followed: natively with the full glibc testsuite for x86_64 (GCC 11, 7, 6) and x86 (GCC 11); with build-many-glibcs.py with GCC 11, 7 and 6; cross testing of math/ tests for powerpc64le, powerpc32 hard float, mips64 (all three ABIs, both hard and soft float). The different GCC versions are to cover the different cases in tgmath.h and tgmath.h tests properly (GCC 6 has _Float* only as typedefs in glibc headers, GCC 7 has proper _Float* support, GCC 8 adds __builtin_tgmath).
* Extend struct r_debug to support multiple namespaces [BZ #15971]H.J. Lu2021-09-191-1/+10
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Glibc does not provide an interface for debugger to access libraries loaded in multiple namespaces via dlmopen. The current rtld-debugger interface is described in the file: elf/rtld-debugger-interface.txt under the "Standard debugger interface" heading. This interface only provides access to the first link-map (LM_ID_BASE). 1. Bump r_version to 2 when multiple namespaces are used. This triggers the GDB bug: https://sourceware.org/bugzilla/show_bug.cgi?id=28236 2. Add struct r_debug_extended to extend struct r_debug into a linked-list, where each element correlates to an unique namespace. 3. Initialize the r_debug_extended structure. Bump r_version to 2 for the new namespace and add the new namespace to the namespace linked list. 4. Add _dl_debug_update to return the address of struct r_debug' of a namespace. 5. Add a hidden symbol, _r_debug_extended, for struct r_debug_extended. 6. Provide the symbol, _r_debug, with size of struct r_debug, as an alias of _r_debug_extended, for programs which reference _r_debug. This fixes BZ #15971. Reviewed-by: Florian Weimer <fweimer@redhat.com>
* Add narrowing square root functionsJoseph Myers2021-09-101-0/+7
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This patch adds the narrowing square root functions from TS 18661-1 / TS 18661-3 / C2X to glibc's libm: fsqrt, fsqrtl, dsqrtl, f32sqrtf64, f32sqrtf32x, f32xsqrtf64 for all configurations; f32sqrtf64x, f32sqrtf128, f64sqrtf64x, f64sqrtf128, f32xsqrtf64x, f32xsqrtf128, f64xsqrtf128 for configurations with _Float64x and _Float128; __f32sqrtieee128 and __f64sqrtieee128 aliases in the powerpc64le case (for calls to fsqrtl and dsqrtl when long double is IEEE binary128). Corresponding tgmath.h macro support is also added. The changes are mostly similar to those for the other narrowing functions previously added, so the description of those generally applies to this patch as well. However, the not-actually-narrowing cases (where the two types involved in the function have the same floating-point format) are aliased to sqrt, sqrtl or sqrtf128 rather than needing a separately built not-actually-narrowing function such as was needed for add / sub / mul / div. Thus, there is no __nldbl_dsqrtl name for ldbl-opt because no such name was needed (whereas the other functions needed such a name since the only other name for that entry point was e.g. f32xaddf64, not reserved by TS 18661-1); the headers are made to arrange for sqrt to be called in that case instead. The DIAG_* calls in sysdeps/ieee754/soft-fp/s_dsqrtl.c are because they were observed to be needed in GCC 7 testing of riscv32-linux-gnu-rv32imac-ilp32. The other sysdeps/ieee754/soft-fp/ files added didn't need such DIAG_* in any configuration I tested with build-many-glibcs.py, but if they do turn out to be needed in more files with some other configuration / GCC version, they can always be added there. I reused the same test inputs in auto-libm-test-in as for non-narrowing sqrt rather than adding extra or separate inputs for narrowing sqrt. The tests in libm-test-narrow-sqrt.inc also follow those for non-narrowing sqrt. Tested as followed: natively with the full glibc testsuite for x86_64 (GCC 11, 7, 6) and x86 (GCC 11); with build-many-glibcs.py with GCC 11, 7 and 6; cross testing of math/ tests for powerpc64le, powerpc32 hard float, mips64 (all three ABIs, both hard and soft float). The different GCC versions are to cover the different cases in tgmath.h and tgmath.h tests properly (GCC 6 has _Float* only as typedefs in glibc headers, GCC 7 has proper _Float* support, GCC 8 adds __builtin_tgmath).
* Add generic C.UTF-8 locale (Bug 17318)Carlos O'Donell2021-09-061-1/+9
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | We add a new C.UTF-8 locale. This locale is not builtin to glibc, but is provided as a distinct locale. The locale provides full support for UTF-8 and this includes full code point sorting via STRCMP-based collation (strcmp or wcscmp). The collation uses a new keyword 'codepoint_collation' which drops all collation rules and generates an empty zero rules collation to enable STRCMP usage in collation. This ensures that we get full code point sorting for C.UTF-8 with a minimal 1406 bytes of overhead (LC_COLLATE structure information and ASCII collating tables). The new locale is added to SUPPORTED. Minimal test data for specific code points (minus those not supported by collate-test) is provided in C.UTF-8.in, and this verifies code point sorting is working reasonably across the range. The locale was tested manually with the full set of code points without failure. The locale is harmonized with locales already shipping in various downstream distributions. A new tst-iconv9 test is added which verifies the C.UTF-8 locale is generally usable. Testing for fnmatch, regexec, and recomp is provided by extending bug-regex1, bugregex19, bug-regex4, bug-regex6, transbug, tst-fnmatch, tst-regcomp-truncated, and tst-regex to use C.UTF-8. Tested on x86_64 or i686 without regression. Reviewed-by: Florian Weimer <fweimer@redhat.com>
* Open master branch for glibc 2.35 development glibc-2.34.9000Carlos O'Donell2021-08-011-0/+24
|
* Update NEWS.Carlos O'Donell2021-08-011-4/+172
| | | | | | | | | Suggestions by Florian Weimer, Andreas Schwab, and Alexander Monakov. See: https://sourceware.org/pipermail/libc-alpha/2021-July/129356.html https://sourceware.org/pipermail/libc-alpha/2021-July/129357.html https://sourceware.org/pipermail/libc-alpha/2021-July/129361.html
* NEWS: Fix typos, grammar, and missing wordsMark Harris2021-08-011-12/+13
| | | | Reviewed-by: Carlos O'Donell <carlos@redhat.com>
* Remove malloc hooks [BZ #23328]Siddhesh Poyarekar2021-07-221-0/+10
| | | | | | | | | | | | | | Make malloc hooks symbols compat-only so that new applications cannot link against them and remove the declarations from the API. Also remove the unused malloc-hooks.h. Finally, mark all symbols in libc_malloc_debug.so as compat so that the library cannot be linked against. Add a note about the deprecation in NEWS. Reviewed-by: Carlos O'Donell <carlos@redhat.com> Tested-by: Carlos O'Donell <carlos@redhat.com>
* Move malloc_{g,s}et_state to libc_malloc_debugSiddhesh Poyarekar2021-07-221-0/+5
| | | | | | | | | | | | | | | | | | | | | | | These deprecated functions are only safe to call from __malloc_initialize_hook and as a result, are not useful in the general case. Move the implementations to libc_malloc_debug so that existing binaries that need it will now have to preload the debug DSO to work correctly. This also allows simplification of the core malloc implementation by dropping all the undumping support code that was added to make malloc_set_state work. One known breakage is that of ancient emacs binaries that depend on this. They will now crash when running with this libc. With LD_BIND_NOW=1, it will terminate immediately because of not being able to find malloc_set_state but with lazy binding it will crash in unpredictable ways. It will need a preloaded libc_malloc_debug.so so that its initialization hook is executed to allow its malloc implementation to work properly. Reviewed-by: Carlos O'Donell <carlos@redhat.com> Tested-by: Carlos O'Donell <carlos@redhat.com>
* Move malloc hooks into a compat DSOSiddhesh Poyarekar2021-07-221-0/+6
| | | | | | | | | | | | | | | | | | | | | | | | Remove all malloc hook uses from core malloc functions and move it into a new library libc_malloc_debug.so. With this, the hooks now no longer have any effect on the core library. libc_malloc_debug.so is a malloc interposer that needs to be preloaded to get hooks functionality back so that the debugging features that depend on the hooks, i.e. malloc-check, mcheck and mtrace work again. Without the preloaded DSO these debugging features will be nops. These features will be ported away from hooks in subsequent patches. Similarly, legacy applications that need hooks functionality need to preload libc_malloc_debug.so. The symbols exported by libc_malloc_debug.so are maintained at exactly the same version as libc.so. Finally, static binaries will no longer be able to use malloc debugging features since they cannot preload the debugging DSO. Reviewed-by: Carlos O'Donell <carlos@redhat.com> Tested-by: Carlos O'Donell <carlos@redhat.com>
* Remove __morecore and __default_morecoreSiddhesh Poyarekar2021-07-221-0/+5
| | | | | | | | | | Make the __morecore and __default_morecore symbols compat-only and remove their declarations from the API. Also, include morecore.c directly into malloc.c; this should ideally get merged into malloc in a future cleanup. Reviewed-by: Carlos O'Donell <carlos@redhat.com> Tested-by: Carlos O'Donell <carlos@redhat.com>
* resolv: Deprecate legacy interfaces in libresolvFlorian Weimer2021-07-191-0/+14
| | | | | | | | | | | | | | | | | | | | | | | | | | | | Debugging interfaces: p_*, fp_*, and sym_* could conceivably be used to produce debug out, but these functions have not been updated to parse more resource records, so they are not very useful today. Likewise for ns_sprintrr and ns_sprintrrf. ns_format_ttl and ns_parse_ttl are related to these. Internal implementation details: res_isourserver is probably only useful in the implementation of a stub resolver, and so is res_nameinquery. Unclear semantics and bad performance: ns_samedomain, ns_subdomain, ns_makecanon, ns_samename do textual converions & copies instead of checking equivalence of the wire format. inet_neta cannot handle IPv6 addresses. res_hostalias has been superseded by getaddrinfo with AI_CANONNAME. hostalias is not thread-safe. Some functions have int as size arguments instead of size_t, so they do not follow current coding practices. However, dn_expand and b64_ntop are somewhat widely used (to name just two examples), so deprecating them seems problematic. Reviewed-by: Carlos O'Donell <carlos@systemhalted.org>
* Define PTHREAD_STACK_MIN to sysconf(_SC_THREAD_STACK_MIN)H.J. Lu2021-07-091-2/+6
| | | | | | | | | | | | | The constant PTHREAD_STACK_MIN may be too small for some processors. Rename _SC_SIGSTKSZ_SOURCE to _DYNAMIC_STACK_SIZE_SOURCE. When _DYNAMIC_STACK_SIZE_SOURCE or _GNU_SOURCE are defined, define PTHREAD_STACK_MIN to sysconf(_SC_THREAD_STACK_MIN) which is changed to MIN (PTHREAD_STACK_MIN, sysconf(_SC_MINSIGSTKSZ)). Consolidate <bits/local_lim.h> with <bits/pthread_stack_min.h> to provide a constant target specific PTHREAD_STACK_MIN value. Reviewed-by: Carlos O'Donell <carlos@redhat.com>
generated by cgit-pink 1.4.1 (git 2.36.1) at 2024-11-05 17:06:28 +0000