aboutsummaryrefslogtreecommitdiff
path: root/sysdeps/mach/hurd/x86_64
AgeCommit message (Collapse)Author
2024-01-01Update copyright dates with scripts/update-copyrightsPaul Eggert
2023-11-23Remove __access_noerrnoJoseph Myers
A recent commit, apparently commit 6c6fce572fb8f583f14d898e54fd7d25ae91cf56 "elf: Remove /etc/suid-debug support", resulted in localplt failures for i686-gnu and x86_64-gnu: Missing required PLT reference: ld.so: __access_noerrno After that commit, __access_noerrno is actually no longer used at all. So rather than just removing the localplt expectation for that symbol for Hurd, completely remove all definitions of and references to that symbol. Tested for x86_64, and with build-many-glibcs.py for i686-gnu and x86_64-gnu.
2023-10-30crypt: Remove libcrypt supportAdhemerval Zanella
All the crypt related functions, cryptographic algorithms, and make requirements are removed, with only the exception of md5 implementation which is moved to locale folder since it is required by localedef for integrity protection (libc's locale-reading code does not check these, but localedef does generate them). Besides thec code itself, both internal documentation and the manual is also adjusted. This allows to remove both --enable-crypt and --enable-nss-crypt configure options. Checked with a build for all affected ABIs. Co-authored-by: Zack Weinberg <zack@owlfolio.org> Reviewed-by: Carlos O'Donell <carlos@redhat.com>
2023-09-28hurd: Drop REG_GSFS and REG_ESDS from x86_64's ucontextSamuel Thibault
These are useless on x86_64, and __NGREG was actually wrong with them.
2023-08-24htl: move pthread_attr_setdetachstate into libcGuy-Fleury Iteriteka
Signed-off-by: Guy-Fleury Iteriteka <gfleury@disroot.org> Message-Id: <20230716084414.107245-11-gfleury@disroot.org>
2023-08-24htl: move pthread_attr_getdetachstate into libcGuy-Fleury Iteriteka
Signed-off-by: Guy-Fleury Iteriteka <gfleury@disroot.org> Message-Id: <20230716084414.107245-10-gfleury@disroot.org>
2023-08-24htl: move pthread_attr_setschedpolicy into libcGuy-Fleury Iteriteka
Signed-off-by: Guy-Fleury Iteriteka <gfleury@disroot.org> Message-Id: <20230716084414.107245-9-gfleury@disroot.org>
2023-08-24htl: move pthread_attr_getschedpolicy into libcGuy-Fleury Iteriteka
Signed-off-by: Guy-Fleury Iteriteka <gfleury@disroot.org> Message-Id: <20230716084414.107245-8-gfleury@disroot.org>
2023-08-24htl: move pthread_attr_setinheritsched into libcGuy-Fleury Iteriteka
Signed-off-by: Guy-Fleury Iteriteka <gfleury@disroot.org> Message-Id: <20230716084414.107245-7-gfleury@disroot.org>
2023-08-24htl: move pthread_attr_getinheritsched into libcGuy-Fleury Iteriteka
Signed-off-by: Guy-Fleury Iteriteka <gfleury@disroot.org> Message-Id: <20230716084414.107245-6-gfleury@disroot.org>
2023-08-24htl: move pthread_attr_getschedparam into libcGuy-Fleury Iteriteka
Signed-off-by: Guy-Fleury Iteriteka <gfleury@disroot.org> Message-Id: <20230716084414.107245-5-gfleury@disroot.org>
2023-08-24htl: move pthread_setschedparam into libcGuy-Fleury Iteriteka
Signed-off-by: Guy-Fleury Iteriteka <gfleury@disroot.org> Message-Id: <20230716084414.107245-4-gfleury@disroot.org>
2023-08-24htl: move pthread_getschedparam into libcGuy-Fleury Iteriteka
Signed-off-by: Guy-Fleury Iteriteka <gfleury@disroot.org> Message-Id: <20230716084414.107245-3-gfleury@disroot.org>
2023-08-24htl: move pthread_equal into libcGuy-Fleury Iteriteka
Signed-off-by: Guy-Fleury Iteriteka <gfleury@disroot.org> Message-Id: <20230716084414.107245-2-gfleury@disroot.org>
2023-06-15hurd: Add strlcpy, strlcat, wcslcpy, wcslcat to libc.abilistFlorian Weimer
2023-06-04hurd: Fix x86_64 sigreturn restoring bogus reply_portSergey Bugaev
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>
2023-06-02Fix a few more typos I missed in previous round -- BZ 25337Paul Pluzhnikov
2023-05-23mach: Fix accessing mach_i386.hSamuel Thibault
Fixes: 196358ae26aa ("mach: Fix installing mach_i386.h")
2023-05-20hurd: Use __hurd_fail () instead of assigning errnoSergey Bugaev
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>
2023-05-19hurd: Fix using interposable hurd_thread_selfSergey Bugaev
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>
2023-05-19hurd: Fix expected c++ typesSamuel Thibault
90604f670c10 ("hurd 64bit: Add data for check-c++-types") actually added the 32bit version. This fixes it into a 64bit version.
2023-05-17hurd: Also make it possible to call strlen very earlySergey Bugaev
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>
2023-05-17hurd: Fix setting up pthreadsSergey Bugaev
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>
2023-05-17hurd: Fix x86_64 _hurd_tls_forkSergey Bugaev
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>
2023-05-17hurd: Make sure to not use tcb->selfSergey Bugaev
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>
2023-05-16hurd: Fix computing user stack pointerSergey Bugaev
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>
2023-05-16hurd: Fix sc_i386_thread_state layoutSergey Bugaev
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>
2023-05-06hurd: Fix ld.so nameSamuel Thibault
This was set to ld-x86-64.so.1 in gcc.
2023-05-06hurd: Add ioperm symbol on x86_64Samuel Thibault
2023-05-01hurd 64bit: Add data for check-c++-typesSamuel Thibault
2023-05-01hurd 64bit: Add missing data file for check-localplt testSamuel Thibault
2023-05-01hurd 64bit: Add missing libanlSamuel Thibault
The move of libanl to libc was in glibc 2.34 for nptl only.
2023-05-01hurd: Also XFAIL missing SA_NOCLDWAIT on 64bitSamuel Thibault
2023-05-01hurd: Add expected abilist files for x86_64Sergey Bugaev
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: Make it possible to call memcpy very earlySergey Bugaev
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 Bugaev
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 Bugaev
Signed-off-by: Sergey Bugaev <bugaevc@gmail.com> Message-Id: <20230429201822.2605207-2-bugaevc@gmail.com>
2023-04-21hurd: Don't migrate reply port into __init1_tcbheadSergey Bugaev
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-14hurd: Only check for TLS initialization inside rtld or in static buildsSergey Bugaev
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-11Revert "hurd: Only check for TLS initialization inside rtld or in static builds"Samuel Thibault
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 Bugaev
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: Only check for TLS initialization inside rtld or in static buildsSergey Bugaev
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: Implement x86_64/intr-msg.hSergey Bugaev
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 Bugaev
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-03hurd: Add vm_param.h for x86_64Sergey Bugaev
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 Bugaev
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 Bugaev
Signed-off-by: Sergey Bugaev <bugaevc@gmail.com> Message-Id: <20230319151017.531737-23-bugaevc@gmail.com>
2023-02-27hurd: Implement TLS for x86_64Sergey Bugaev
Signed-off-by: Sergey Bugaev <bugaevc@gmail.com> Message-Id: <20230221211932.296459-4-bugaevc@gmail.com>
2023-02-12hurd, htl: Add some x86_64-specific codeSergey Bugaev
Signed-off-by: Sergey Bugaev <bugaevc@gmail.com> Message-Id: <20230212111044.610942-12-bugaevc@gmail.com>
2023-02-12hurd: Set up the basic tree for x86_64-gnuSergey Bugaev
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>
generated by cgit v1.2.3 (git 2.25.1) at 2024-10-21 14:56:06 +0000