about summary refs log tree commit diff
path: root/sysdeps/mach
Commit message (Collapse)AuthorAgeFilesLines
* hurd: Add strlcpy, strlcat, wcslcpy, wcslcat to libc.abilistFlorian Weimer2023-06-151-0/+8
|
* 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>
* hurd: Fix x86_64 sigreturn restoring bogus reply_portSergey Bugaev2023-06-041-38/+46
| | | | | | | | | | Since the area of the user's stack we use for the registers dump (and otherwise as __sigreturn2's stack) can and does overlap the sigcontext, we have to be very careful about the order of loads and stores that we do. In particular we have to load sc_reply_port before we start clobbering the sigcontext. Signed-off-by: Sergey Bugaev <bugaevc@gmail.com>
* Fix a few more typos I missed in previous round -- BZ 25337Paul Pluzhnikov2023-06-021-1/+1
|
* Fix misspellings in sysdeps/ -- BZ 25337Paul Pluzhnikov2023-05-3010-11/+11
|
* hurd: Fix setting up signal thread stack alignmentSamuel Thibault2023-05-281-7/+5
| | | | | x86_64 needs special alignment when calling functions, so we have to use MACHINE_THREAD_STATE_SETUP_CALL for the signal thread when forking.
* mach: Fix accessing mach_i386.hSamuel Thibault2023-05-234-4/+8
| | | | Fixes: 196358ae26aa ("mach: Fix installing mach_i386.h")
* mach: Fix installing mach_i386.hSamuel Thibault2023-05-232-2/+2
| | | | | | We do not want mach_i386.h to get installed into machine/, but into i386/ or x86_64/ depending where mach_i386.defs was found, i.e. according to 32/64 bitness.
* hurd: Fix making ld.so run static binaries with retrySamuel Thibault2023-05-231-1/+1
| | | | We need O_EXEC for __rtld_execve
* hurd: Use __hurd_fail () instead of assigning errnoSergey Bugaev2023-05-2044-242/+95
| | | | | | | | | | | | | | 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-193-4/+7
| | | | | | | | | | | | 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 __TIMESIZE on x86_64Sergey Bugaev2023-05-192-1/+5
| | | | | | | We had sizeof (time_t) == 8, but __TIMESIZE == 32. Signed-off-by: Sergey Bugaev <bugaevc@gmail.com> Message-Id: <20230519171516.3698754-1-bugaevc@gmail.com>
* hurd: Fix expected c++ typesSamuel Thibault2023-05-191-19/+19
| | | | | 90604f670c10 ("hurd 64bit: Add data for check-c++-types") actually added the 32bit version. This fixes it into a 64bit version.
* hurd: Also make it possible to call strlen very earlySergey Bugaev2023-05-171-0/+3
| | | | | | | | | | | | strlen, which is another ifunc-selected function, is invoked during early static executable startup if the argv arrives from the exec server. Make it not crash. Checked on x86_64-gnu: statically linked executables launched after the exec server is up now start up successfully. Signed-off-by: Sergey Bugaev <bugaevc@gmail.com> Message-Id: <20230517191436.73636-10-bugaevc@gmail.com>
* hurd: Fix setting up pthreadsSergey Bugaev2023-05-172-1/+94
| | | | | | | | | | | | | | | | | | | | 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: Fix x86_64 _hurd_tls_forkSergey Bugaev2023-05-171-6/+19
| | | | | | | | | | | | | | | It is illegal to call thread_get_state () on mach_thread_self (), so this codepath cannot be used as-is to fork the calling thread's TLS. Fortunately we can use THREAD_SELF (aka %fs:0x0) to find out the value of our fs_base without calling into the kernel. Fixes: f6cf701efc61c9ad910372bda14b9a235db310a8 "hurd: Implement TLS for x86_64" Checked on x86_64-gnu: fork () now works! Signed-off-by: Sergey Bugaev <bugaevc@gmail.com> Message-Id: <20230517191436.73636-8-bugaevc@gmail.com>
* hurd: Make sure to not use tcb->selfSergey Bugaev2023-05-173-26/+14
| | | | | | | | | | | | | | | | | | | | 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: Use __mach_setup_thread_call ()Sergey Bugaev2023-05-172-7/+9
| | | | | | | | | | | ...instead of mach_setup_thread (), which is unsuitable for setting up function calls. Checked on x86_64-gnu: the signal thread no longer crashes upon trying to process a message. Signed-off-by: Sergey Bugaev <bugaevc@gmail.com> Message-Id: <20230517191436.73636-6-bugaevc@gmail.com>
* mach: Define MACHINE_THREAD_STATE_SETUP_CALLSergey Bugaev2023-05-172-0/+22
| | | | | | | | | | | | | | | | | | | | | The existing two macros, MACHINE_THREAD_STATE_SET_PC and MACHINE_THREAD_STATE_SET_SP, can be used to set program counter and the stack pointer registers in a machine-specific thread state structure. Useful as it is, this may not be enough to set up the thread to make a function call, because the machine-specific ABI may impose additional requirements. In particular, x86_64 ABI requires that upon function entry, the stack pointer is 8 less than 16-byte aligned (sp & 15 == 8). To deal with this, introduce a new macro, MACHINE_THREAD_STATE_SETUP_CALL (), which sets both stack and instruction pointers, and also applies any machine-specific requirements to make a valid function call. The default implementation simply forwards to MACHINE_THREAD_STATE_SET_PC and MACHINE_THREAD_STATE_SET_SP, but on x86_64 we additionally align the stack pointer. Signed-off-by: Sergey Bugaev <bugaevc@gmail.com> Message-Id: <20230517191436.73636-3-bugaevc@gmail.com>
* Use TASK_THREAD_TIMES_INFO_COUNT when calling task_info with ↵Flavio Cruz2023-05-171-1/+1
| | | | | | | | | TASK_THREAD_TIMES_INFO This hasn't caused any problems yet but we are passing a pointer to struct task_thread_times_info which can cause problems if we populate over the existing size of the struct. Message-Id: <ZGRDDNcOM2hA3CuT@jupiter.tail36e24.ts.net>
* hurd: Fix computing user stack pointerSergey Bugaev2023-05-161-1/+1
| | | | | | | | | | Fixes b574ae0a2876ee94e4fe617f878407bf818c2df0 "hurd: Implement sigreturn for x86_64" Checked on x86_64-gnu. Signed-off-by: Sergey Bugaev <bugaevc@gmail.com> Message-Id: <20230515083323.1358039-5-bugaevc@gmail.com>
* hurd: Fix sc_i386_thread_state layoutSergey Bugaev2023-05-162-0/+14
| | | | | | | | | | | | | | | | | | | The real i386_thread_state Mach structure has an alignment of 8 on x86_64. However, in struct sigcontext, the compiler was packing sc_gs (which is the first member of sc_i386_thread_state) into the same 8-byte slot as sc_error; this resulted in the rest of sc_i386_thread_state members having wrong offsets relative to each other, and the overall sc_i386_thread_state layout mismatching that of i386_thread_state. Fix this by explicitly adding the required padding members, and statically asserting that this results in the desired alignment. The same goes for sc_i386_float_state. Checked on x86_64-gnu. Signed-off-by: Sergey Bugaev <bugaevc@gmail.com> Message-Id: <20230515083323.1358039-4-bugaevc@gmail.com>
* hurd: Align signal stack pointer after allocating stackframeSergey Bugaev2023-05-161-3/+2
| | | | | | | | | | | sizeof (*stackframe) appears to be divisible by 16, but we should not rely on that. So make sure to leave enough space for the stackframe first, and then align the final pointer at 16 bytes. Checked on x86_64-gnu. Signed-off-by: Sergey Bugaev <bugaevc@gmail.com> Message-Id: <20230515083323.1358039-3-bugaevc@gmail.com>
* hurd: Fix aligning signal stack pointerSergey Bugaev2023-05-161-1/+1
| | | | | | | | | | | Fixes 60f9bf974694d50daf58d46347b06a5975ac5ddd "hurd: Port trampoline.c to x86_64" Checked on x86_64-gnu. Reported-by: Bruno Haible <bruno@clisp.org> Signed-off-by: Sergey Bugaev <bugaevc@gmail.com> Message-Id: <20230515083323.1358039-2-bugaevc@gmail.com>
* hurd: rule out some mach headers when generating errno.hSamuel Thibault2023-05-112-3/+4
| | | | | | | | | | While mach/kern_return.h happens to pull mach/machine/kern_return.h, mach/machine/boolean.h, and mach/machine/vm_types.h (and realpath-ing them exposes the machine-specific machine symlink content), those headers do not actually define anything machine-specific for the content of errno.h. So we can just rule out these machine-specific from the dependency comment.
* Stop checking if MiG supports retcode.Flavio Cruz2023-05-112-62/+0
| | | | | | | | | | | | | | | | We already did the same change for Hurd (https://git.savannah.gnu.org/cgit/hurd/hurd.git/commit/?id=ef5924402864ef049f40a39e73967628583bc1a4) Due to MiG requiring the subsystem to be defined early in order to know the size of a port, this was causing a division by zero error during ./configure. We could have just move subsystem to the top of the snippet, however it is simpler to just remove the check given that we have no plans to use some other MiG anyway. HAVE_MIG_RETCODE is removed completely since this will be a no-op either way (compiling against old Hurd headers will work the same, new Hurd headers will result in the same stubs since retcode is a no-op). Message-Id: <ZFspor91aoMwbh9T@jupiter.tail36e24.ts.net>
* Update hurd/hurdselect.c to be more portable.Flavio Cruz2023-05-062-5/+31
| | | | | | | | | | | Summary of changes: - Use BAD_TYPECHECK to perform type checking in a cleaner way. BAD_TYPECHECK is moved into sysdeps/mach/rpc.h to avoid duplication. - Remove assertions for mach_msg_type_t since those won't work for x86_64. - Update message structs to use mach_msg_type_t directly. - Use designated initializers. Message-Id: <ZFa+roan3ioo0ONM@jupiter.tail36e24.ts.net>
* hurd: Fix ld.so nameSamuel Thibault2023-05-061-0/+1
| | | | This was set to ld-x86-64.so.1 in gcc.
* hurd: Add ioperm symbol on x86_64Samuel Thibault2023-05-062-0/+6
|
* Update sysdeps/mach/hurd/ioctl.c to make it more portableFlavio Cruz2023-05-051-20/+27
| | | | | | | | | | | | | | | Summary of the changes: - Update msg_align to use ALIGN_UP like we have done in previous patches. Use it below whenever necessary to avoid repeating the same alignment logic. - Define BAD_TYPECHECK to make it easier to do type checking in a few places below. - Update io2mach_type to use designated initializers. - Make RetCodeType use mach_msg_type_t. mach_msg_type_t is 8 byte for x86_64, so this make it portable. - Also call msg_align for _IOT_COUNT2/_IOT_TYPE2 since it is more correct. Message-Id: <ZFMvVsuFKwIy2dUS@jupiter.tail36e24.ts.net>
* hurd 64bit: Make dev_t word typeSamuel Thibault2023-05-021-1/+1
| | | | | | | dev_t are 64bit on Linux ports, so better increase their size on 64bit Hurd. It happens that this helps with BZ 23084 there: st_dev has type fsid_t (quad) and is specified by POSIX to have type dev_t. Making dev_t 64bit makes these match.
* 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-014-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.
* hurd 64bit: Add data for check-c++-typesSamuel Thibault2023-05-011-0/+67
|
* 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 64bit: Add missing data file for check-localplt testSamuel Thibault2023-05-011-0/+44
|
* hurd 64bit: Add missing libanlSamuel Thibault2023-05-011-0/+4
| | | | The move of libanl to libc was in glibc 2.34 for nptl only.
* hurd: Also XFAIL missing SA_NOCLDWAIT on 64bitSamuel Thibault2023-05-011-0/+5
|
* hurd: Add expected abilist files for x86_64Sergey Bugaev2023-05-0112-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>
* hurd: Replace reply port with a dead name on failed interruptionSergey Bugaev2023-05-011-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>
* Define __mig_strlen to support dynamically sized strings in hurd RPCsFlavio Cruz2023-05-011-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>
* hurd: Make it possible to call memcpy very earlySergey Bugaev2023-05-011-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>
* hurd: Implement longjmp for x86_64Sergey Bugaev2023-05-012-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>
* hurd: Implement sigreturn for x86_64Sergey Bugaev2023-05-011-0/+162
| | | | | Signed-off-by: Sergey Bugaev <bugaevc@gmail.com> Message-Id: <20230429201822.2605207-2-bugaevc@gmail.com>
* hurd: Make _exit work during early boot-upSergey Bugaev2023-04-291-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>
* Fix Hurd getcwd build with GCC >= 13Joseph Myers2023-04-271-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>
* Regenerate sysdeps/mach/hurd/bits/errno.hJoseph Myers2023-04-261-0/+19
| | | | | This file was out of date, as shown by build-many-glibcs.py runs resulting in a modified source directory.
* hurd: Do not take any flag from the CMSG_DATASamuel Thibault2023-04-251-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.
generated by cgit-pink 1.4.1 (git 2.36.1) at 2024-11-06 02:40:46 +0000