about summary refs log tree commit diff
path: root/sysdeps/mach/hurd/i386
Commit message (Collapse)AuthorAgeFilesLines
* hurd: Fix missing pthread_ compat symbol in libcSamuel Thibault2024-08-011-0/+10
| | | | | | | | | | | | | | | | 5476f8cd2e68 ("htl: move pthread_self info libc.") and 9dfa2562162b ("htl: move pthread_equal into libc") to 1dc0bc8f0748 ("htl: move pthread_attr_setdetachstate into libc") moved some pthread_ symbols from libpthread.so to libc.so, but missed adding the compat version like 5476f8cd2e68 ("htl: move pthread_self info libc.") did: libc already had these symbols as forwards, but versioned GLIBC_2.21, while the symbols in libpthread.so were versioned GLIBC_2.12. To fix running executables built before this, we thus have to add the GLIBC_2.12 version, otherwise execution fails with e.g. /usr/lib/i386-gnu/libglib-2.0.so: symbol lookup error: /usr/lib/i386-gnu/libglib-2.0.so: undefined symbol: pthread_attr_setinheritsched, version GLIBC_2.12
* Add pthread_getname_np and pthread_setname_np for HurdFlavio Cruz2024-07-161-0/+2
| | | | | | | | | | | We use thread_get_name and thread_set_name to get and set the thread name, so nothing is stored in the thread structure since these functions are supposed to be called sparingly. One notable difference with Linux is that the thread name is up to 32 chars, whereas Linux's is 16. Also added a mach_RPC_CHECK to check for the existing of gnumach RPCs.
* Implement C23 exp2m1, exp10m1Joseph Myers2024-06-171-0/+16
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | C23 adds various <math.h> function families originally defined in TS 18661-4. Add the exp2m1 and exp10m1 functions (exp2(x)-1 and exp10(x)-1, like expm1). As with other such functions, these use type-generic templates that could be replaced with faster and more accurate type-specific implementations in future. Test inputs are copied from those for expm1, plus some additions close to the overflow threshold (copied from exp2 and exp10) and also some near the underflow threshold. exp2m1 has the unusual property of having an input (M_MAX_EXP) where whether the function overflows (under IEEE semantics) depends on the rounding mode. Although these could reasonably be XFAILed in the testsuite (as we do in some cases for arguments very close to a function's overflow threshold when an error of a few ulps in the implementation can result in the implementation not agreeing with an ideal one on whether overflow takes place - the testsuite isn't smart enough to handle this automatically), since these functions aren't required to be correctly rounding, I made the implementation check for and handle this case specially. The Makefile ordering expected by lint-makefiles for the new functions is a bit peculiar, but I implemented it in this patch so that the test passes; I don't know why log2 also needed moving in one Makefile variable setting when it didn't in my previous patches, but the failure showed a different place was expected for that function as well. The powerpc64le IFUNC setup seems not to be as self-contained as one might hope; it shouldn't be necessary to add IFUNCs for new functions such as these simply to get them building, but without setting up IFUNCs for the new functions, there were undefined references to __GI___expm1f128 (that IFUNC machinery results in no such function being defined, but doesn't stop include/math.h from doing the redirection resulting in the exp2m1f128 and exp10m1f128 implementations expecting to call it). Tested for x86_64 and x86, and with build-many-glibcs.py.
* Implement C23 log10p1Joseph Myers2024-06-171-0/+8
| | | | | | | | | | | | | | C23 adds various <math.h> function families originally defined in TS 18661-4. Add the log10p1 functions (log10(1+x): like log1p, but for base-10 logarithms). This is directly analogous to the log2p1 implementation (except that whereas log2p1 has a smaller underflow range than log1p, log10p1 has a larger underflow range). The test inputs are copied from those for log1p and log2p1, plus a few more inputs in that wider underflow range. Tested for x86_64 and x86, and with build-many-glibcs.py.
* Implement C23 logp1Joseph Myers2024-06-171-0/+8
| | | | | | | | | | | | | | | | | | | | | | | | | | | C23 adds various <math.h> function families originally defined in TS 18661-4. Add the logp1 functions (aliases for log1p functions - the name is intended to be more consistent with the new log2p1 and log10p1, where clearly it would have been very confusing to name those functions log21p and log101p). As aliases rather than new functions, the content of this patch is somewhat different from those actually adding new functions. Tests are shared with log1p, so this patch *does* mechanically update all affected libm-test-ulps files to expect the same errors for both functions. The vector versions of log1p on aarch64 and x86_64 are *not* updated to have logp1 aliases (and thus there are no corresponding header, tests, abilist or ulps changes for vector functions either). It would be reasonable for such vector aliases and corresponding changes to other files to be made separately. For now, the log1p tests instead avoid testing logp1 in the vector case (a Makefile change is needed to avoid problems with grep, used in generating the .c files for vector function tests, matching more than one ALL_RM_TEST line in a file testing multiple functions with the same inputs, when it assumes that the .inc file only has a single such line). Tested for x86_64 and x86, and with build-many-glibcs.py.
* Implement C23 log2p1Joseph Myers2024-05-201-0/+8
| | | | | | | | | | | | | | | | | | | | | | | | C23 adds various <math.h> function families originally defined in TS 18661-4. Add the log2p1 functions (log2(1+x): like log1p, but for base-2 logarithms). This illustrates the intended structure of implementations of all these function families: define them initially with a type-generic template implementation. If someone wishes to add type-specific implementations, it is likely such implementations can be both faster and more accurate than the type-generic one and can then override it for types for which they are implemented (adding benchmarks would be desirable in such cases to demonstrate that a new implementation is indeed faster). The test inputs are copied from those for log1p. Note that these changes make gen-auto-libm-tests depend on MPFR 4.2 (or later). The bulk of the changes are fairly generic for any such new function. (sysdeps/powerpc/nofpu/Makefile only needs changing for those type-generic templates that use fabs.) Tested for x86_64 and x86, and with build-many-glibcs.py.
* hurd: Pass the data pointer to _hurd_stack_setup explicitlySergey Bugaev2024-01-041-0/+3
| | | | | | | | | Instead of relying on the stack frame layout to figure out where the stack pointer was prior to the _hurd_stack_setup () call, just pass the pointer as an argument explicitly. This is less brittle and much more portable. Signed-off-by: Sergey Bugaev <bugaevc@gmail.com> Message-ID: <20240103171502.1358371-8-bugaevc@gmail.com>
* Implement C23 <stdbit.h>Joseph Myers2024-01-031-0/+70
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | C23 adds a header <stdbit.h> with various functions and type-generic macros for bit-manipulation of unsigned integers (plus macro defines related to endianness). Implement this header for glibc. The functions have both inline definitions in the header (referenced by macros defined in the header) and copies with external linkage in the library (which are implemented in terms of those macros to avoid duplication). They are documented in the glibc manual. Tests, as well as verifying results for various inputs (of both the macros and the out-of-line functions), verify the types of those results (which showed up a bug in an earlier version with the type-generic macro stdc_has_single_bit wrongly returning a promoted type), that the macros can be used at top level in a source file (so don't use ({})), that they evaluate their arguments exactly once, and that the macros for the type-specific functions have the expected implicit conversions to the relevant argument type. Jakub previously referred to -Wconversion warnings in type-generic macros, so I've included a test with -Wconversion (but the only warnings I saw and fixed from that test were actually in inline functions in the <stdbit.h> header - not anything coming from use of the type-generic macros themselves). This implementation of the type-generic macros does not handle unsigned __int128, or unsigned _BitInt types with a width other than that of a standard integer type (and C23 doesn't require the header to handle such types either). Support for those types, using the new type-generic built-in functions Jakub's added for GCC 14, can reasonably be added in a followup (along of course with associated tests). This implementation doesn't do anything special to handle C++, or have any tests of functionality in C++ beyond the existing tests that all headers can be compiled in C++ code; it's not clear exactly what form this header should take in C++, but probably not one using macros. DIS ballot comment AT-107 asks for the word "count" to be added to the names of the stdc_leading_zeros, stdc_leading_ones, stdc_trailing_zeros and stdc_trailing_ones functions and macros. I don't think it's likely to be accepted (accepting any technical comments would mean having an FDIS ballot), but if it is accepted at the WG14 meeting (22-26 January in Strasbourg, starting with DIS ballot comment handling) then there would still be time to update glibc for the renaming before the 2.39 release. The new functions and header are placed in the stdlib/ directory in glibc, rather than creating a new toplevel stdbit/ or putting them in string/ alongside ffs. Tested for x86_64 and x86.
* Update copyright dates with scripts/update-copyrightsPaul Eggert2024-01-0123-23/+23
|
* Remove __access_noerrnoJoseph Myers2023-11-231-1/+0
| | | | | | | | | | | | | | | | 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.
* crypt: Remove libcrypt supportAdhemerval Zanella2023-10-301-7/+0
| | | | | | | | | | | | | | | | | | 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>
* 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.
generated by cgit-pink 1.4.1 (git 2.36.1) at 2024-10-03 04:58:37 +0000