about summary refs log tree commit diff
path: root/sysdeps/mach/hurd/i386
Commit message (Collapse)AuthorAgeFilesLines
* htl: move pthread_attr_setdetachstate into libcGuy-Fleury Iteriteka2023-08-241-1/+0
| | | | | Signed-off-by: Guy-Fleury Iteriteka <gfleury@disroot.org> Message-Id: <20230716084414.107245-11-gfleury@disroot.org>
* htl: move pthread_attr_getdetachstate into libcGuy-Fleury Iteriteka2023-08-241-1/+0
| | | | | Signed-off-by: Guy-Fleury Iteriteka <gfleury@disroot.org> Message-Id: <20230716084414.107245-10-gfleury@disroot.org>
* htl: move pthread_attr_setschedpolicy into libcGuy-Fleury Iteriteka2023-08-241-1/+0
| | | | | Signed-off-by: Guy-Fleury Iteriteka <gfleury@disroot.org> Message-Id: <20230716084414.107245-9-gfleury@disroot.org>
* htl: move pthread_attr_getschedpolicy into libcGuy-Fleury Iteriteka2023-08-241-1/+0
| | | | | Signed-off-by: Guy-Fleury Iteriteka <gfleury@disroot.org> Message-Id: <20230716084414.107245-8-gfleury@disroot.org>
* htl: move pthread_attr_setinheritsched into libcGuy-Fleury Iteriteka2023-08-241-1/+0
| | | | | Signed-off-by: Guy-Fleury Iteriteka <gfleury@disroot.org> Message-Id: <20230716084414.107245-7-gfleury@disroot.org>
* htl: move pthread_attr_getinheritsched into libcGuy-Fleury Iteriteka2023-08-241-1/+0
| | | | | Signed-off-by: Guy-Fleury Iteriteka <gfleury@disroot.org> Message-Id: <20230716084414.107245-6-gfleury@disroot.org>
* htl: move pthread_attr_getschedparam into libcGuy-Fleury Iteriteka2023-08-241-1/+0
| | | | | Signed-off-by: Guy-Fleury Iteriteka <gfleury@disroot.org> Message-Id: <20230716084414.107245-5-gfleury@disroot.org>
* htl: move pthread_setschedparam into libcGuy-Fleury Iteriteka2023-08-241-1/+0
| | | | | Signed-off-by: Guy-Fleury Iteriteka <gfleury@disroot.org> Message-Id: <20230716084414.107245-4-gfleury@disroot.org>
* htl: move pthread_getschedparam into libcGuy-Fleury Iteriteka2023-08-241-1/+0
| | | | | Signed-off-by: Guy-Fleury Iteriteka <gfleury@disroot.org> Message-Id: <20230716084414.107245-3-gfleury@disroot.org>
* htl: move pthread_equal into libcGuy-Fleury Iteriteka2023-08-241-1/+0
| | | | | Signed-off-by: Guy-Fleury Iteriteka <gfleury@disroot.org> Message-Id: <20230716084414.107245-2-gfleury@disroot.org>
* Add the wcslcpy, wcslcat functionsFlorian Weimer2023-06-141-0/+4
| | | | | | | These functions are about to be added to POSIX, under Austin Group issue 986. Reviewed-by: Siddhesh Poyarekar <siddhesh@sourceware.org>
* Implement strlcpy and strlcat [BZ #178]Florian Weimer2023-06-141-0/+4
| | | | | | | | | | | These functions are about to be added to POSIX, under Austin Group issue 986. The fortified strlcat implementation does not raise SIGABRT if the destination buffer does not contain a null terminator, it just inherits the non-failing regular strlcat behavior. Reviewed-by: Siddhesh Poyarekar <siddhesh@sourceware.org>
* Fix misspellings in sysdeps/ -- BZ 25337Paul Pluzhnikov2023-05-301-1/+1
|
* mach: Fix accessing mach_i386.hSamuel Thibault2023-05-232-2/+2
| | | | Fixes: 196358ae26aa ("mach: Fix installing mach_i386.h")
* hurd: Use __hurd_fail () instead of assigning errnoSergey Bugaev2023-05-201-4/+1
| | | | | | | | | | | | | | The __hurd_fail () inline function is the dedicated, idiomatic way of reporting errors in the Hurd part of glibc. Not only is it more concise than '{ errno = err; return -1; }', it is since commit 6639cc10029e24e06b34e169712b21c31b8cf213 "hurd: Mark error functions as __COLD" marked with the cold attribute, telling the compiler that this codepath is unlikely to be executed. In one case, use __hurd_dfail () over the plain __hurd_fail (). Signed-off-by: Sergey Bugaev <bugaevc@gmail.com> Message-Id: <20230520115531.3911877-1-bugaevc@gmail.com>
* hurd: Fix using interposable hurd_thread_selfSergey Bugaev2023-05-191-1/+1
| | | | | | | | | | | | Create a private hidden __hurd_thread_self alias, and use that one. Fixes 2f8ecb58a59eb82c43214d000842d99644a662d1 "hurd: Fix x86_64 _hurd_tls_fork" and c7fcce38c83a2bb665ef5dc4981bf20c7e586123 "hurd: Make sure to not use tcb->self" Reported-by: Joseph Myers <joseph@codesourcery.com> Signed-off-by: Sergey Bugaev <bugaevc@gmail.com>
* hurd: Fix setting up pthreadsSergey Bugaev2023-05-171-0/+100
| | | | | | | | | | | | | | | | | | | | On x86_64, we have to pass function arguments in registers, not on the stack. We also have to align the stack pointer in a specific way. Since sharing the logic with i386 does not bring much benefit, split the file back into i386- and x86_64-specific versions, and fix the x86_64 version to set up the thread properly. Bonus: i386 keeps doing the extra RPC inside __thread_set_pcsptp to fetch the state of the thread before setting it; but x86_64 no lnoger does that. Checked on x86_64-gnu and i686-gnu. Fixes be6d002ca277ffc90058d382396150cb0e785b9c "hurd: Set up the basic tree for x86_64-gnu" Signed-off-by: Sergey Bugaev <bugaevc@gmail.com> Message-Id: <20230517191436.73636-9-bugaevc@gmail.com>
* hurd: Make sure to not use tcb->selfSergey Bugaev2023-05-171-2/+1
| | | | | | | | | | | | | | | | | | | | Unlike sigstate->thread, tcb->self did not hold a Mach port reference on the thread port it names. This means that the port can be deallocated, and the name reused for something else, without anyone noticing. Using tcb->self will then lead to port use-after-free. Fortunately nothing was accessing tcb->self, other than it being intially set to then-valid thread port name upon TCB initialization. To assert that this keeps being the case without altering TCB layout, rename self -> self_do_not_use, and stop initializing it. Also, do not (re-)allocate a whole separate and unused stack for the main thread, and just exit __pthread_setup early in this case. Found upon attempting to use tcb->self and getting unexpected crashes. Signed-off-by: Sergey Bugaev <bugaevc@gmail.com> Message-Id: <20230517191436.73636-7-bugaevc@gmail.com>
* hurd 64bit: Fix struct msqid_ds and shmid_ds fieldsSamuel Thibault2023-05-012-0/+83
| | | | | | | | The standards want msg_lspid/msg_lrpid/shm_cpid/shm_lpid to be pid_t, see BZ 23083 and 23085. We can leave them __rpc_pid_t on i386 for ABI compatibility, but avoid hitting the issue on 64bit.
* hurd 64bit: Fix ipc_perm fields typesSamuel Thibault2023-05-011-0/+33
| | | | | | | | | | | The standards want uid/cuid to be uid_t, gid/cgid to be gid_t and mode to be mode_t, see BZ 23082. We can leave them short ints on i386 for ABI compatibility, but avoid hitting the issue on 64bit. bits/ipc.h ends up being exactly the same in sysdeps/gnu/ and sysdeps/unix/sysv/linux/, so remove the latter.
* hurd 64bit: Fix flock fields typesSamuel Thibault2023-05-011-0/+46
| | | | | | | The standards want l_type and l_whence to be short ints, see BZ 23081. We can leave them ints on i386 for ABI compatibility, but avoid hitting the issue on 64bit.
* hurd 64bit: Fix pthread_t/thread_t type to longSamuel Thibault2023-05-012-0/+48
| | | | So that they can be trivially cast to pointer type, like with nptl.
* 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.
generated by cgit-pink 1.4.1 (git 2.36.1) at 2024-11-05 06:50:47 +0000