aboutsummaryrefslogtreecommitdiff
path: root/sysdeps/mach
AgeCommit message (Collapse)AuthorFilesLines
2023-05-01hurd 64bit: Fix flock fields typesSamuel Thibault4-27/+95
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.
2023-05-01hurd 64bit: Add data for check-c++-typesSamuel Thibault1-0/+67
2023-05-01hurd 64bit: Fix pthread_t/thread_t type to longSamuel Thibault2-0/+48
So that they can be trivially cast to pointer type, like with nptl.
2023-05-01hurd 64bit: Add missing data file for check-localplt testSamuel Thibault1-0/+44
2023-05-01hurd 64bit: Add missing libanlSamuel Thibault1-0/+4
The move of libanl to libc was in glibc 2.34 for nptl only.
2023-05-01hurd: Also XFAIL missing SA_NOCLDWAIT on 64bitSamuel Thibault1-0/+5
2023-05-01hurd: Add expected abilist files for x86_64Sergey Bugaev12-0/+3687
These were created by creating stub files, running 'make update-abi', and reviewing the results. Also, set baseline ABI to GLIBC_2.38, the (upcoming) first glibc release to first have x86_64-gnu support. Signed-off-by: Sergey Bugaev <bugaevc@gmail.com>
2023-05-01hurd: Replace reply port with a dead name on failed interruptionSergey Bugaev1-18/+7
If we're trying to interrupt an interruptible RPC, but the server fails to respond to our __interrupt_operation () call, we instead destroy the reply port we were expecting the reply to the RPC on. Instead of deallocating the name completely, replace it with a dead name, so the name won't get reused for some other right, and deallocate it in _hurd_intr_rpc_mach_msg once we return from the signal handler. Signed-off-by: Sergey Bugaev <bugaevc@gmail.com> Message-Id: <20230429201822.2605207-4-bugaevc@gmail.com>
2023-05-01Define __mig_strlen to support dynamically sized strings in hurd RPCsFlavio Cruz1-1/+2
We make lib{mach,hurd}user.so only call __mig_strlen which can be relocated before libc.so is relocated, similar to what is done with __mig_memcpy. Message-Id: <ZE8DTRDpY2hpPZlJ@jupiter.tail36e24.ts.net>
2023-05-01hurd: Make it possible to call memcpy very earlySergey Bugaev1-0/+3
Normally, in static builds, the first code that runs is _start, in e.g. sysdeps/x86_64/start.S, which quickly calls __libc_start_main, passing it the argv etc. Among the first things __libc_start_main does is initializing the tunables (based on env), then CPU features, and then calls _dl_relocate_static_pie (). Specifically, this runs ifunc resolvers to pick, based on the CPU features discovered earlier, the most suitable implementation of "string" functions such as memcpy. Before that point, calling memcpy (or other ifunc-resolved functions) will not work. In the Hurd port, things are more complex. In order to get argv/env for our process, glibc normally needs to do an RPC to the exec server, unless our args/env are already located on the stack (which is what happens to bootstrap processes spawned by GNU Mach). Fetching our argv/env from the exec server has to be done before the call to __libc_start_main, since we need to know what our argv/env are to pass them to __libc_start_main. On the other hand, the implementation of the RPC (and other initial setup needed on the Hurd before __libc_start_main can be run) is not very trivial. In particular, it may (and on x86_64, will) use memcpy. But as described above, calling memcpy before __libc_start_main can not work, since the GOT entry for it is not yet initialized at that point. Work around this by pre-filling the GOT entry with the baseline version of memcpy, __memcpy_sse2_unaligned. This makes it possible for early calls to memcpy to just work. The initial value of the GOT entry is unused on x86_64, and changing it won't interfere with the relocation being performed later: once _dl_relocate_static_pie () is called, the baseline version will get replaced with the most suitable one, and that is what subsequent calls of memcpy are going to call. Checked on x86_64-gnu. Signed-off-by: Sergey Bugaev <bugaevc@gmail.com> Message-Id: <20230429201822.2605207-6-bugaevc@gmail.com>
2023-05-01hurd: Implement longjmp for x86_64Sergey Bugaev2-0/+219
Checked on x86_64-gnu. [samuel.thibault@ens-lyon.org: Restored same comments as on i386] Signed-off-by: Sergey Bugaev <bugaevc@gmail.com> Message-Id: <20230429201822.2605207-3-bugaevc@gmail.com>
2023-05-01hurd: Implement sigreturn for x86_64Sergey Bugaev1-0/+162
Signed-off-by: Sergey Bugaev <bugaevc@gmail.com> Message-Id: <20230429201822.2605207-2-bugaevc@gmail.com>
2023-04-29hurd: Make _exit work during early boot-upSergey Bugaev1-2/+3
If any of the early boot-up tasks calls exit () or returns from main (), terminate it properly instead of crashing on trying to dereference _hurd_ports and getting forcibly terminated by the kernel. We sadly cannot make the __USEPORT macro do the check for _hurd_ports being unset, because it evaluates to the value of the expression provided as the second argument, and that can be of any type; so there is no single suitable fallback value for the macro to evaluate to in case _hurd_ports is unset. Instead, each use site that wants to care for this case will have to do its own checking. Checked on x86_64-gnu. Signed-off-by: Sergey Bugaev <bugaevc@gmail.com> Message-Id: <20230429131354.2507443-4-bugaevc@gmail.com>
2023-04-27Fix Hurd getcwd build with GCC >= 13Joseph Myers1-2/+3
The build of glibc for i686-gnu has been failing for a while with GCC mainline / GCC 13: ../sysdeps/mach/hurd/getcwd.c: In function '__hurd_canonicalize_directory_name_internal': ../sysdeps/mach/hurd/getcwd.c:242:48: error: pointer 'file_name' may be used after 'realloc' [-Werror=use-after-free] 242 | file_namep = &buf[file_namep - file_name + size / 2]; | ~~~~~~~~~~~^~~~~~~~~~~ ../sysdeps/mach/hurd/getcwd.c:236:25: note: call to 'realloc' here 236 | buf = realloc (file_name, size); | ^~~~~~~~~~~~~~~~~~~~~~~~~ Fix by doing the subtraction before the reallocation. Tested with build-many-glibcs.py for i686-gnu. [samuel.thibault@ens-lyon.rg: Removed mention of this being a bug] Message-Id: <18587337-7815-4056-ebd0-724df262d591@codesourcery.com>
2023-04-26Regenerate sysdeps/mach/hurd/bits/errno.hJoseph Myers1-0/+19
This file was out of date, as shown by build-many-glibcs.py runs resulting in a modified source directory.
2023-04-25hurd: Do not take any flag from the CMSG_DATASamuel Thibault1-1/+3
As fixed in 0822e3552a78 ("hurd: Don't pass FD_CLOEXEC in CMSG_DATA"), senders currently don't have any flag to pass. We shouldn't blindly take random flags that senders could be erroneously giving us.
2023-04-24hurd: Implement MSG_CMSG_CLOEXECSergey Bugaev2-2/+7
This is a new flag that can be passed to recvmsg () to make it atomically set the CLOEXEC flag on all the file descriptors received using the SCM_RIGHTS mechanism. This is useful for all the same reasons that the other XXX_CLOEXEC flags are useful: namely, it provides atomicity with respect to another thread of the same process calling (fork and then) exec at the same time. This flag is already supported on Linux and FreeBSD. The flag's value, 0x40000, is choosen to match FreeBSD's. Signed-off-by: Sergey Bugaev <bugaevc@gmail.com> Message-Id: <20230423160548.126576-2-bugaevc@gmail.com>
2023-04-24hurd: Don't pass FD_CLOEXEC in CMSG_DATASamuel Thibault1-2/+2
The flags are used by _hurd_intern_fd, which takes O_* flags, not FD_*. Also, it is of no concern to the receiving process whether or not the sender process wants to close its copy of sent file descriptor upon exec, and it should not influence whether or not the received file descriptor gets the FD_CLOEXEC flag set in the receiving process. The latter should in fact be dependent on the MSG_CMSG_CLOEXEC flag being passed to the recvmsg () call, which is going to be implemented in the following commit. Fixes 344e755248ce02c0f8d095d11cc49e340703d926 "hurd: Support sending file descriptors over Unix sockets" Signed-off-by: Samuel Thibault <samuel.thibault@ens-lyon.org> Signed-off-by: Sergey Bugaev <bugaevc@gmail.com>
2023-04-24hurd: Implement prefer_map_32bit_exec tunableSergey Bugaev2-0/+11
This makes the prefer_map_32bit_exec tunable no longer Linux-specific. Signed-off-by: Sergey Bugaev <bugaevc@gmail.com> Message-Id: <20230423215526.346009-4-bugaevc@gmail.com>
2023-04-24hurd: Don't attempt to deallocate MACH_PORT_DEADSergey Bugaev2-4/+4
...in some more places. Signed-off-by: Sergey Bugaev <bugaevc@gmail.com> Message-Id: <20230423215526.346009-2-bugaevc@gmail.com>
2023-04-24hurd: Only deallocate addrport when it's validSergey Bugaev5-6/+10
Signed-off-by: Sergey Bugaev <bugaevc@gmail.com> Message-Id: <20230423160548.126576-3-bugaevc@gmail.com>
2023-04-24hurd: Implement MAP_32BITSergey Bugaev3-7/+12
This is a flag that can be passed to mmap () to request that the mapping being established should be located in the lower 2 GB area of the address space, so only the lower 31 (not 32) bits can be set in its address, and the address can be represented as a 32-bit integer without truncating it. This flag is intended to be compatible with Linux, FreeBSD, and Darwin flags of the same name. Out of those systems, it appears Linux and FreeBSD take MAP_32BIT to mean "map 31 bit", whereas Darwin allows the 32nd bit to be set in the address as well. The Hurd follows Linux and FreeBSD behavior. Unlike on those systems, on the Hurd MAP_32BIT is defined on all supported architectures (which currently are only i386 and x86_64). Signed-off-by: Sergey Bugaev <bugaevc@gmail.com> Message-Id: <20230423215526.346009-1-bugaevc@gmail.com>
2023-04-21hurd: Don't migrate reply port into __init1_tcbheadSergey Bugaev3-17/+19
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>
2023-04-20hurd: Make dl-sysdep's open () cope with O_IGNORE_CTTYSergey Bugaev1-2/+2
Signed-off-by: Sergey Bugaev <bugaevc@gmail.com> Message-Id: <20230419160207.65988-6-bugaevc@gmail.com>
2023-04-18hurd: Microoptimize sigreturnSergey Bugaev1-3/+9
Signed-off-by: Sergey Bugaev <bugaevc@gmail.com>
2023-04-17hurd: Fix restoring reply port in sigreturnSergey Bugaev1-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>
2023-04-14hurd: Only check for TLS initialization inside rtld or in static buildsSergey Bugaev6-33/+83
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>
2023-04-14hurd: Remove __hurd_local_reply_portSergey Bugaev3-14/+60
Now that the signal code no longer accesses it, the only real user of it was mig-reply.c, so move the logic for managing the port there. If we're in SHARED and outside of rtld, we know that __LIBC_NO_TLS () always evaluates to 0, and a TLS reply port will always be used, not __hurd_reply_port0. Still, the compiler does not see that __hurd_reply_port0 is never used due to its address being taken. To deal with this, explicitly compile out __hurd_reply_port0 when we know we won't use it. Also, instead of accessing the port via THREAD_SELF->reply_port, this uses THREAD_GETMEM and THREAD_SETMEM directly, avoiding possible miscompilations. Signed-off-by: Sergey Bugaev <bugaevc@gmail.com>
2023-04-13hurd: Mark two tests as unsupportedSamuel Thibault1-0/+10
They make the whole testsuite hang/crash.
2023-04-13hurd: Restore destroying receive rights on sigreturnSamuel Thibault1-2/+2
Just subtracting a ref is making signal/tst-signal signal/tst-raise signal/tst-minsigstksz-5 htl/tst-raise1 fail.
2023-04-11Revert "hurd: Only check for TLS initialization inside rtld or in static builds"Samuel Thibault6-83/+33
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.
2023-04-11hurd: Don't leak __hurd_reply_port0Sergey Bugaev2-1/+13
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>
2023-04-10hurd: Improve reply port handling when exiting signal handlersSergey Bugaev1-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>
2023-04-10hurd: Only check for TLS initialization inside rtld or in static buildsSergey Bugaev6-34/+85
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>
2023-04-10hurd: Port trampoline.c to x86_64Sergey Bugaev1-7/+151
Signed-off-by: Sergey Bugaev <bugaevc@gmail.com> Message-Id: <20230403115621.258636-3-bugaevc@gmail.com>
2023-04-10hurd: Do not declare local variables volatileSergey Bugaev1-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>
2023-04-10hurd: Implement x86_64/intr-msg.hSergey Bugaev1-0/+119
Signed-off-by: Sergey Bugaev <bugaevc@gmail.com> Message-Id: <20230319151017.531737-18-bugaevc@gmail.com>
2023-04-10hurd: Add sys/ucontext.h and sigcontext.h for x86_64Sergey Bugaev2-0/+169
This is based on the Linux port's version, but laid out to match Mach's struct i386_thread_state, much like the i386 version does. Signed-off-by: Sergey Bugaev <bugaevc@gmail.com>
2023-04-10hurd: Stop depending on the default_pager stubs provided by gnumachFlavio Cruz2-4/+2
The hurd source tree already provides the same stubs and they are only needed there. Message-Id: <ZDN3rDdjMowtUWf7@jupiter.tail36e24.ts.net>
2023-04-05htl: move pthread_self info libc.Guy-Fleury Iteriteka2-2/+2
Signed-off-by: Guy-Fleury Iteriteka <gfleury@disroot.org> Message-Id: <20230318095826.1125734-4-gfleury@disroot.org>
2023-04-05htl: move ___pthread_self into libc.Guy-Fleury Iteriteka3-2/+25
sysdeps/mach/hurd/htl/pt-pthread_self.c: New file. htl/Makefile: .. Add it to libc routine. sysdeps/mach/hurd/htl/pt-sysdep.c(__pthread_self): Remove it. sysdeps/mach/hurd/htl/pt-sysdep.h(__pthread_self): Add hidden propertie. htl/Versions(__pthread_self) Version it as private symbol. Signed-off-by: Guy-Fleury Iteriteka <gfleury@disroot.org> Message-Id: <20230318095826.1125734-3-gfleury@disroot.org>
2023-04-03hurd: Add vm_param.h for x86_64Sergey Bugaev1-0/+24
Signed-off-by: Sergey Bugaev <bugaevc@gmail.com> Message-Id: <20230319151017.531737-30-bugaevc@gmail.com>
2023-04-03hurd: Implement _hurd_longjmp_thread_state for x86_64Sergey Bugaev1-0/+41
Signed-off-by: Sergey Bugaev <bugaevc@gmail.com> Message-Id: <20230319151017.531737-29-bugaevc@gmail.com>
2023-04-03htl: Implement thread_set_pcsptp for x86_64Sergey Bugaev1-0/+73
Signed-off-by: Sergey Bugaev <bugaevc@gmail.com> Message-Id: <20230319151017.531737-23-bugaevc@gmail.com>
2023-04-03hurd: Move a couple of signal-related files to x86Sergey Bugaev2-0/+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>
2023-04-03hurd: Use uintptr_t for register values in trampoline.cSergey Bugaev1-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>
2023-04-03hurd: Move rtld-strncpy-c.c out of mach/hurd/Sergey Bugaev1-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>
2023-04-03hurd: More 64-bit integer casting fixesSergey Bugaev2-4/+4
Signed-off-by: Sergey Bugaev <bugaevc@gmail.com> Message-Id: <20230319151017.531737-13-bugaevc@gmail.com>
2023-04-03mach, hurd: Drop __libc_lock_self0Sergey Bugaev3-8/+3
This was used for the value of libc-lock's owner when TLS is not yet set up, so THREAD_SELF can not be used. Since the value need not be anything specific -- it just has to be non-NULL -- we can just use a plain constant, such as (void *) 1, for this. This avoids accessing the symbol through GOT, and exporting it from libc.so in the first place. Signed-off-by: Sergey Bugaev <bugaevc@gmail.com> Message-Id: <20230319151017.531737-12-bugaevc@gmail.com>
2023-04-03hurd: Remove __hurd_threadvar_stack_{offset,mask}Sergey Bugaev4-26/+2
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>
generated by cgit v1.1 at 2025-09-18 19:05:57 +0000