about summary refs log tree commit diff
path: root/sysdeps/mach/hurd/i386
Commit message (Collapse)AuthorAgeFilesLines
* hurd: Don't migrate reply port into __init1_tcbheadSergey Bugaev2023-04-211-6/+12
| | | | | | | | | | | | | | | Properly differentiate between setting up the real TLS with TLS_INIT_TP, and setting up the early TLS (__init1_tcbhead) in static builds. In the latter case, don't yet migrate the reply port into the TCB, and don't yet set __libc_tls_initialized to 1. This also lets us move the __init1_desc assignment inside _hurd_tls_init (). Fixes cd019ddd892e182277fadd6aedccc57fa3923c8d "hurd: Don't leak __hurd_reply_port0" Signed-off-by: Sergey Bugaev <bugaevc@gmail.com>
* hurd: Microoptimize sigreturnSergey Bugaev2023-04-181-3/+9
| | | | Signed-off-by: Sergey Bugaev <bugaevc@gmail.com>
* hurd: Fix restoring reply port in sigreturnSergey Bugaev2023-04-171-12/+23
| | | | | | | | | We must not use the user's reply port (scp->sc_reply_port) for any of our own RPCs, otherwise various things break. So, use MACH_PORT_DEAD as a reply port when destroying our reply port, and make sure to do this after _hurd_sigstate_unlock (), which may do a gsync_wake () RPC. Signed-off-by: Sergey Bugaev <bugaevc@gmail.com>
* hurd: Only check for TLS initialization inside rtld or in static buildsSergey Bugaev2023-04-142-17/+47
| | | | | | | | | | | | | | | | | | | | | When glibc is built as a shared library, TLS is always initialized by the call of TLS_INIT_TP () macro made inside the dynamic loader, prior to running the main program (see dl-call_tls_init_tp.h). We can take advantage of this: we know for sure that __LIBC_NO_TLS () will evaluate to 0 in all other cases, so let the compiler know that explicitly too. Also, only define _hurd_tls_init () and TLS_INIT_TP () under the same conditions (either !SHARED or inside rtld), to statically assert that this is the case. Other than a microoptimization, this also helps with avoiding awkward sharing of the __libc_tls_initialized variable between ld.so and libc.so that we would have to do otherwise -- we know for sure that no sharing is required, simply because __libc_tls_initialized would always be set to true inside libc.so. Signed-off-by: Sergey Bugaev <bugaevc@gmail.com> Message-Id: <20230319151017.531737-25-bugaevc@gmail.com>
* hurd: Restore destroying receive rights on sigreturnSamuel Thibault2023-04-131-2/+2
| | | | | Just subtracting a ref is making signal/tst-signal signal/tst-raise signal/tst-minsigstksz-5 htl/tst-raise1 fail.
* Revert "hurd: Only check for TLS initialization inside rtld or in static builds"Samuel Thibault2023-04-112-47/+17
| | | | | | | | This reverts commit b37899d34d2190ef4b454283188f22519f096048. Apparently we load libc.so (and thus start using its functions) before calling TLS_INIT_TP, so libc.so functions should not actually assume that TLS is always set up.
* hurd: Don't leak __hurd_reply_port0Sergey Bugaev2023-04-111-0/+5
| | | | | | | | | | | | | Previously, once we set up TLS, we would implicitly switch from using __hurd_reply_port0 to reply_port inside the TCB, leaving the former unused. But we never deallocated it, so it got leaked. Instead, migrate the port into the new TCB's reply_port slot. This avoids both the port leak and an extra syscall to create a new reply port for the TCB. Signed-off-by: Sergey Bugaev <bugaevc@gmail.com> Message-Id: <20230319151017.531737-28-bugaevc@gmail.com>
* hurd: Improve reply port handling when exiting signal handlersSergey Bugaev2023-04-101-16/+5
| | | | | | | | | | | | | | | | | If we're doing signals, that means we've already got the signal thread running, and that implies TLS having been set up. So we know that __hurd_local_reply_port will resolve to THREAD_SELF->reply_port, and can access that directly using the THREAD_GETMEM and THREAD_SETMEM macros. This avoids potential miscompilations, and should also be a tiny bit faster. Also, use mach_port_mod_refs () and not mach_port_destroy () to destroy the receive right. mach_port_destroy () should *never* be used on mach_task_self (); this can easily lead to port use-after-free vulnerabilities if the task has any other references to the same port. Signed-off-by: Sergey Bugaev <bugaevc@gmail.com> Message-Id: <20230319151017.531737-26-bugaevc@gmail.com>
* hurd: Only check for TLS initialization inside rtld or in static buildsSergey Bugaev2023-04-102-17/+47
| | | | | | | | | | | | | | | | | | | | | When glibc is built as a shared library, TLS is always initialized by the call of TLS_INIT_TP () macro made inside the dynamic loader, prior to running the main program (see dl-call_tls_init_tp.h). We can take advantage of this: we know for sure that __LIBC_NO_TLS () will evaluate to 0 in all other cases, so let the compiler know that explicitly too. Also, only define _hurd_tls_init () and TLS_INIT_TP () under the same conditions (either !SHARED or inside rtld), to statically assert that this is the case. Other than a microoptimization, this also helps with avoiding awkward sharing of the __libc_tls_initialized variable between ld.so and libc.so that we would have to do otherwise -- we know for sure that no sharing is required, simply because __libc_tls_initialized would always be set to true inside libc.so. Signed-off-by: Sergey Bugaev <bugaevc@gmail.com> Message-Id: <20230319151017.531737-25-bugaevc@gmail.com>
* hurd: Port trampoline.c to x86_64Sergey Bugaev2023-04-101-341/+0
| | | | | Signed-off-by: Sergey Bugaev <bugaevc@gmail.com> Message-Id: <20230403115621.258636-3-bugaevc@gmail.com>
* hurd: Do not declare local variables volatileSergey Bugaev2023-04-101-2/+2
| | | | | | | | | | | | | | These are just regular local variables that are not accessed in any funny ways, not even though a pointer. There's absolutely no reason to declare them volatile. It only ends up hurting the quality of the generated machine code. If anything, it would make sense to decalre sigsp as *pointing* to volatile memory (volatile void *sigsp), but evidently that's not needed either. Signed-off-by: Sergey Bugaev <bugaevc@gmail.com> Message-Id: <20230403115621.258636-2-bugaevc@gmail.com>
* htl: move pthread_self info libc.Guy-Fleury Iteriteka2023-04-052-2/+2
| | | | | Signed-off-by: Guy-Fleury Iteriteka <gfleury@disroot.org> Message-Id: <20230318095826.1125734-4-gfleury@disroot.org>
* hurd: Move a couple of signal-related files to x86Sergey Bugaev2023-04-032-206/+0
| | | | | | | These do not need any changes to be used on x86_64. Signed-off-by: Sergey Bugaev <bugaevc@gmail.com> Message-Id: <20230319151017.531737-20-bugaevc@gmail.com>
* hurd: Use uintptr_t for register values in trampoline.cSergey Bugaev2023-04-031-7/+6
| | | | | | | | | | | | This is more correct, if only because these fields are defined as having the type unsigned int in the Mach headers, so casting them to a signed int and then back is suboptimal. Also, remove an extra reassignment of uesp -- this is another remnant of the ecx kludge. Signed-off-by: Sergey Bugaev <bugaevc@gmail.com> Message-Id: <20230319151017.531737-16-bugaevc@gmail.com>
* hurd: Move rtld-strncpy-c.c out of mach/hurd/Sergey Bugaev2023-04-031-1/+0
| | | | | | | | There's nothing Mach- or Hurd-specific about it; any port that ends up with rtld pulling in strncpy will need this. Signed-off-by: Sergey Bugaev <bugaevc@gmail.com> Message-Id: <20230319151017.531737-15-bugaevc@gmail.com>
* hurd: Remove __hurd_threadvar_stack_{offset,mask}Sergey Bugaev2023-04-031-2/+0
| | | | | | | | | | | Noone is or should be using __hurd_threadvar_stack_{offset,mask}, we have proper TLS now. These two remaining variables are never set to anything other than zero, so any code that would try to use them as described would just dereference a zero pointer and crash. So remove them entirely. Signed-off-by: Sergey Bugaev <bugaevc@gmail.com> Message-Id: <20230319151017.531737-6-bugaevc@gmail.com>
* C2x scanf binary constant handlingJoseph Myers2023-03-021-0/+12
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | C2x adds binary integer constants starting with 0b or 0B, and supports those constants for the %i scanf format (in addition to the %b format, which isn't yet implemented for scanf in glibc). Implement that scanf support for glibc. As with the strtol support, 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 input potentially matching subsequent parts of the scanf format string). Thus this patch adds 12 new __isoc23_* functions per long double format (12, 24 or 36 depending on how many long double formats the glibc configuration supports), with appropriate header redirection support (generally very closely following that for the __isoc99_* scanf functions - note that __GLIBC_USE (DEPRECATED_SCANF) takes precedence over __GLIBC_USE (C2X_STRTOL), so the case of GNU extensions to C89 continues to get old-style GNU %a and does not get this new feature). The function names would remain as __isoc23_* even if C2x ends up published in 2024 rather than 2023. When scanf %b support is added, I think it will be appropriate for all versions of scanf to follow C2x rules for inputs to the %b format (given that there are no compatibility concerns for a new format). Tested for x86_64 (full glibc testsuite). The first version was also tested for powerpc (32-bit) and powerpc64le (stdio-common/ and wcsmbs/ tests), and with build-many-glibcs.py.
* hurd: Remove the ecx kludgeSergey Bugaev2023-03-022-43/+18
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | "We don't need it any more" The INTR_MSG_TRAP macro in intr-msg.h used to play little trick with the stack pointer: it would temporarily save the "real" stack pointer into ecx, while setting esp to point to just before the message buffer, and then invoke the mach_msg trap. This way, INTR_MSG_TRAP reused the on-stack arguments laid out for the containing call of _hurd_intr_rpc_mach_msg (), passing them to the mach_msg trap directly. This, however, required special support in hurdsig.c and trampoline.c, since they now had to recognize when a thread is inside the piece of code where esp doesn't point to the real tip of the stack, and handle this situation specially. Commit 1d20f33ff4fb634310f27493b7b87d0b20f4a0b0 has removed the actual temporary change of esp by actually re-pushing mach_msg arguments onto the stack, and popping them back at end. It did not, however, deal with the rest of "the ecx kludge" code in other files, resulting in potential crashes if a signal arrives in the middle of pushing arguments onto the stack. Fix that by removing "the ecx kludge". Instead, when we want a thread to skip the RPC, but cannot make just make it jump to after the trap since it's not done adjusting the stack yet, set the SYSRETURN register to MACH_SEND_INTERRUPTED (as we do anyway), and rely on the thread itself for detecting this case and skipping the RPC. This simplifies things somewhat and paves the way for a future x86_64 port of this code. Signed-off-by: Sergey Bugaev <bugaevc@gmail.com> Message-Id: <20230301162355.426887-1-bugaevc@gmail.com>
* hurd: Generalize init-first.c to support x86_64Sergey Bugaev2023-02-241-262/+0
| | | | | Signed-off-by: Sergey Bugaev <bugaevc@gmail.com> Message-Id: <20230223151436.49180-2-bugaevc@gmail.com>
* hurd: Simplify init-first.c furtherSergey Bugaev2023-02-242-139/+61
| | | | | | | | This drops all of the return address rewriting kludges. The only remaining hack is the jump out of a call stack while adjusting the stack pointer. Signed-off-by: Sergey Bugaev <bugaevc@gmail.com>
* hurd: Simplify init-first.c a bitSergey Bugaev2023-02-201-16/+7
| | | | | | | | And make it a bit more 64-bit ready. This is in preparation to moving this file into x86/ Signed-off-by: Sergey Bugaev <bugaevc@gmail.com> Message-Id: <20230218203717.373211-6-bugaevc@gmail.com>
* hurd: Move thread state manipulation into _hurd_tls_new ()Sergey Bugaev2023-02-201-5/+20
| | | | | | | This is going to be done differently on x86_64. Signed-off-by: Sergey Bugaev <bugaevc@gmail.com> Message-Id: <20230218203717.373211-2-bugaevc@gmail.com>
* [hurd] Fix i686 build breakage caused by 4fedebc91108Flavio Cruz2023-02-172-3/+3
| | | | Message-Id: <Y+8bqZzYTl7WaUm7@jupiter.tail36e24.ts.net>
* C2x strtol binary constant handlingJoseph Myers2023-02-161-0/+20
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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.
* hurd: i386 TLS tweaksSergey Bugaev2023-02-141-13/+35
| | | | | | | | | | | | | | * Micro-optimize TLS access using GCC's native support for gs-based addressing when available; * Just use THREAD_GETMEM and THREAD_SETMEM instead of more inline assembly; * Sync tcbhead_t layout with NPTL, in particular update/fix __private_ss offset; * Statically assert that the two offsets that are a part of ABI are what we expect them to be. Signed-off-by: Sergey Bugaev <bugaevc@gmail.com> Message-Id: <20230214173722.428140-2-bugaevc@gmail.com>
* hurd: Set up the basic tree for x86_64-gnuSergey Bugaev2023-02-122-110/+1
| | | | | | | And move pt-setup.c to the generic x86 tree. Signed-off-by: Sergey Bugaev <bugaevc@gmail.com> Message-Id: <20230212111044.610942-11-bugaevc@gmail.com>
* hurd: Fix unwinding over INTR_MSG_TRAPSamuel Thibault2023-02-091-13/+0
| | | | | | | | | | We used to use .cfi_adjust_cfa_offset around %esp manipulation asm instructions to fix unwinding, but when building glibc with -fno-omit-frame-pointer this is bogus since in that case %ebp is the CFA and does not move. Instead, let's force -fno-omit-frame-pointer when building intr-msg.c so that %ebp can always be used and no .cfi_adjust_cfa_offset is needed.
* hurd: Move some i386 bits to x86Samuel Thibault2023-02-023-309/+0
| | | | As they will actually be usable on x86_64 too.
* Update copyright dates with scripts/update-copyrightsJoseph Myers2023-01-0621-21/+21
|
* elf: Introduce <dl-call_tls_init_tp.h> and call_tls_init_tp (bug 29249)Florian Weimer2022-11-031-5/+5
| | | | | | | | This makes it more likely that the compiler can compute the strlen argument in _startup_fatal at compile time, which is required to avoid a dependency on strlen this early during process startup. Reviewed-by: Szabolcs Nagy <szabolcs.nagy@arm.com>
* elf: Rework exception handling in the dynamic loader [BZ #25486]Florian Weimer2022-11-032-5/+3
| | | | | | | | | | | | | | | | | | | | | | | The old exception handling implementation used function interposition to replace the dynamic loader implementation (no TLS support) with the libc implementation (TLS support). This results in problems if the link order between the dynamic loader and libc is reversed (bug 25486). The new implementation moves the entire implementation of the exception handling functions back into the dynamic loader, using THREAD_GETMEM and THREAD_SETMEM for thread-local data support. These depends on Hurd support for these macros, added in commit b65a82e4e757c1e6cb7073916 ("hurd: Add THREAD_GET/SETMEM/_NC"). One small obstacle is that the exception handling facilities are used before the TCB has been set up, so a check is needed if the TCB is available. If not, a regular global variable is used to store the exception handling information. Also rename dl-error.c to dl-catch.c, to avoid confusion with the dlerror function. Reviewed-by: Siddhesh Poyarekar <siddhesh@sourceware.org>
* Introduce <pointer_guard.h>, extracted from <sysdep.h>Florian Weimer2022-10-182-0/+2
| | | | | | | | | | | | | | This allows us to define a generic no-op version of PTR_MANGLE and PTR_DEMANGLE. In the future, we can use PTR_MANGLE and PTR_DEMANGLE unconditionally in C sources, avoiding an unintended loss of hardening due to missing include files or unlucky header inclusion ordering. In i386 and x86_64, we can avoid a <tls.h> dependency in the C code by using the computed constant from <tcb-offsets.h>. <sysdep.h> no longer includes these definitions, so there is no cyclic dependency anymore when computing the <tcb-offsets.h> constants. Reviewed-by: Adhemerval Zanella <adhemerval.zanella@linaro.org>
* hurd: Fix starting static binaries with stack protection enabledSamuel Thibault2022-08-222-2/+22
| | | | | | | gcc introduces gs:0x14 accesses in most functions, so we need some tcbhead to be ready very early during initialization. This configures a static area which can be referenced by various protected functions, until proper TLS is set up.
* hurd: Assume non-suid during bootstrapSamuel Thibault2022-08-191-2/+7
| | | | | | | | We do not have a hurd data block only when bootstrapping the system, in which case we don't have a notion of suid yet anyway. This is needed, otherwise init_standard_fds would check that standard file descriptors are allocated, which is meaningless during bootstrap.
* stdlib: Add arc4random, arc4random_buf, and arc4random_uniform (BZ #4417)Adhemerval Zanella Netto2022-07-221-0/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The implementation is based on scalar Chacha20 with per-thread cache. It uses getrandom or /dev/urandom as fallback to get the initial entropy, and reseeds the internal state on every 16MB of consumed buffer. To improve performance and lower memory consumption the per-thread cache is allocated lazily on first arc4random functions call, and if the memory allocation fails getentropy or /dev/urandom is used as fallback. The cache is also cleared on thread exit iff it was initialized (so if arc4random is not called it is not touched). Although it is lock-free, arc4random is still not async-signal-safe (the per thread state is not updated atomically). The ChaCha20 implementation is based on RFC8439 [1], omitting the final XOR of the keystream with the plaintext because the plaintext is a stream of zeros. This strategy is similar to what OpenBSD arc4random does. The arc4random_uniform is based on previous work by Florian Weimer, where the algorithm is based on Jérémie Lumbroso paper Optimal Discrete Uniform Generation from Coin Flips, and Applications (2013) [2], who credits Donald E. Knuth and Andrew C. Yao, The complexity of nonuniform random number generation (1976), for solving the general case. The main advantage of this method is the that the unit of randomness is not the uniform random variable (uint32_t), but a random bit. It optimizes the internal buffer sampling by initially consuming a 32-bit random variable and then sampling byte per byte. Depending of the upper bound requested, it might lead to better CPU utilization. Checked on x86_64-linux-gnu, aarch64-linux, and powerpc64le-linux-gnu. Co-authored-by: Florian Weimer <fweimer@redhat.com> Reviewed-by: Yann Droneaud <ydroneaud@opteya.com> [1] https://datatracker.ietf.org/doc/html/rfc8439 [2] https://arxiv.org/pdf/1304.1916.pdf
* stdlib: Implement mbrtoc8, c8rtomb, and the char8_t typedef.Tom Honermann2022-07-061-0/+2
| | | | | | | | | | | | | | | | | This change provides implementations for the mbrtoc8 and c8rtomb functions adopted for C++20 via WG21 P0482R6 and for C2X via WG14 N2653. It also provides the char8_t typedef from WG14 N2653. The mbrtoc8 and c8rtomb functions are declared in uchar.h in C2X mode or when the _GNU_SOURCE macro or C++20 __cpp_char8_t feature test macro is defined. The char8_t typedef is declared in uchar.h in C2X mode or when the _GNU_SOURCE macro is defined and the C++20 __cpp_char8_t feature test macro is not defined (if __cpp_char8_t is defined, then char8_t is a builtin type). Reviewed-by: Adhemerval Zanella <adhemerval.zanella@linaro.org>
* elf: Remove __libc_init_secureFangrui Song2022-04-191-4/+0
| | | | | | | | | | | | | | After 73fc4e28b9464f0e13edc719a5372839970e7ddb, __libc_enable_secure_decided is always 0 and a statically linked executable may overwrite __libc_enable_secure without considering AT_SECURE. The __libc_enable_secure has been correctly initialized in _dl_aux_init, so just remove __libc_enable_secure_decided and __libc_init_secure. This allows us to remove some startup_get*id functions from 22b79ed7f413cd980a7af0cf258da5bf82b6d5e5. Reviewed-by: Florian Weimer <fweimer@redhat.com>
* posix: Replace posix_spawnattr_tc{get,set}pgrp_np with ↵Adhemerval Zanella2022-02-021-2/+1
| | | | | | | | | | | | | | | | | | posix_spawn_file_actions_addtcsetpgrp_np The posix_spawnattr_tcsetpgrp_np works on a file descriptor (the controlling terminal), so it would make more sense to actually fit it on the file actions API. Also, POSIX_SPAWN_TCSETPGROUP is not really required since it is implicit by the presence of tcsetpgrp file action. The posix/tst-spawn6.c is also fixed when TTY can is not present. Checked on x86_64-linux-gnu and i686-linux-gnu. Reviewed-by: Carlos O'Donell <carlos@redhat.com> Tested-by: Carlos O'Donell <carlos@redhat.com>
* Fix glibc 2.34 ABI omission (missing GLIBC_2.34 in dynamic loader)Florian Weimer2022-01-271-0/+1
| | | | | | | | | | | | | The glibc 2.34 release really should have added a GLIBC_2.34 symbol to the dynamic loader. With it, we could move functions such as dlopen or pthread_key_create that work on process-global state into the dynamic loader (once we have fixed a longstanding issue with static linking). Without the GLIBC_2.34 symbol, yet another new symbol version would be needed because old glibc will fail to load binaries due to the missing symbol version in ld.so that newly linked programs will require. Reviewed-by: H.J. Lu <hjl.tools@gmail.com>
* hurd: Add posix_spawnattr_tc{get,set}pgrp_np on libc.abilistAdhemerval Zanella2022-01-261-0/+2
| | | | Commit 342cc934a3bf74ac missed the update-abi for the ABI.
* htl: Hide __pthread_attr's __schedparam type [BZ #23088]Samuel Thibault2022-01-151-70/+0
| | | | | | | | | | The content of the structure is only used internally, so we can make __pthread_attr_getschedparam and __pthread_attr_setschedparam convert between the public sched_param type and an internal __sched_param. This allows to avoid to spuriously expose the sched_param type. This fixes BZ #23088.
* Update copyright dates with scripts/update-copyrightsPaul Eggert2022-01-0121-21/+21
| | | | | | | | | | | | | | | | | | | | | | | 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
* hurd: Bump BRK_START to 0x20000000Samuel Thibault2021-12-311-1/+1
| | | | | By nowadays uses, 256MiB is not that large for the program+libraries. Let's push the heap further to leave room for e.g. clang.
* elf: Add _dl_find_object functionFlorian Weimer2021-12-281-0/+1
| | | | | | | | | | | | | | | | | | | | | | | | | 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>
* hurd: Fix static-PIE startupSamuel Thibault2021-12-281-1/+1
| | | | | | | | hurd initialization stages use RUN_HOOK to run various initialization functions. That is however using absolute addresses which need to be relocated, which is done later by csu. We can however easily make the linker compute relative addresses which thus don't need a relocation. The new SET_RELHOOK and RUN_RELHOOK macros implement this.
* hurd: let csu initialize tlsSamuel Thibault2021-12-281-3/+0
| | | | | | | | Since 9cec82de715b ("htl: Initialize later"), we let csu initialize pthreads. We can thus let it initialize tls later too, to better align with the generic order. Initialization however accesses ports which links/unlinks into the sigstate for unwinding. We can however easily skip that during initialization.
* hurd: Fix XFAIL-ing mallocfork2 testsSamuel Thibault2021-12-271-4/+10
| | | | They are using setpshared but are outside the htl directory.
* hurd: XFAIL more tests that require setpshared supportSamuel Thibault2021-12-271-0/+2
|
* math: Remove the error handling wrapper from hypot and hypotfAdhemerval Zanella2021-12-131-0/+2
| | | | | | | | | | | | The error handling is moved to sysdeps/ieee754 version with no SVID support. The compatibility symbol versions still use the wrapper with SVID error handling around the new code. There is no new symbol version nor compatibility code on !LIBM_SVID_COMPAT targets (e.g. riscv). Only ia64 is unchanged, since it still uses the arch specific __libm_error_region on its implementation. Checked on x86_64-linux-gnu, i686-linux-gnu, and aarch64-linux-gnu.
* setjmp: Replace jmp_buf-macros.h with jmp_buf-macros.symAdhemerval Zanella2021-11-221-6/+0
| | | | | | | | | | | | It requires less boilerplate code for newer ports. The _Static_assert checks from internal setjmp are moved to its own internal test since setjmp.h is included early by multiple headers (to generate rtld-sizes.sym). The riscv jmp_buf-macros.h check is also redundant, it is already done by riscv configure.ac. Checked with a build for the affected architectures.
generated by cgit-pink 1.4.1 (git 2.36.1) at 2024-07-24 13:05:03 +0000