about summary refs log tree commit diff
path: root/sysdeps/mach/hurd
Commit message (Collapse)AuthorAgeFilesLines
* Convert to autoconf 2.72 (vanilla release, no distribution patches)Andreas K. Hüttel14 days1-69/+64
| | | | | | | As discussed at the patch review meeting Signed-off-by: Andreas K. Hüttel <dilfridge@gentoo.org> Reviewed-by: Simon Chopin <simon.chopin@canonical.com>
* Implement C23 exp2m1, exp10m1Joseph Myers14 days2-0/+32
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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-172-0/+16
| | | | | | | | | | | | | | 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-172-0/+16
| | | | | | | | | | | | | | | | | | | | | | | | | | | 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.
* hurd: Fix lsetxattr return valueSamuel Thibault2024-06-101-1/+1
| | | | The manpage says that lsetxattr returns 0 on success, like setxattr.
* Implement C23 log2p1Joseph Myers2024-05-202-0/+16
| | | | | | | | | | | | | | | | | | | | | | | | 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.
* socket: Use may_alias on sockaddr structs (bug 19622)Florian Weimer2024-05-181-2/+2
| | | | | | | | | | | | | | This supports common coding patterns. The GCC C front end before version 7 rejects the may_alias attribute on a struct definition if it was not present in a previous forward declaration, so this attribute can only be conditionally applied. This implements the spirit of the change in Austin Group issue 1641. Suggested-by: Marek Polacek <polacek@redhat.com> Suggested-by: Jakub Jelinek <jakub@redhat.com> Reviewed-by: Sam James <sam@gentoo.org> Reviewed-by: Carlos O'Donell <carlos@redhat.com>
* htl: Implement some support for TLS_DTV_AT_TPSergey Bugaev2024-03-231-0/+9
| | | | | Signed-off-by: Sergey Bugaev <bugaevc@gmail.com> Message-ID: <20240323173301.151066-19-bugaevc@gmail.com>
* hurd: Use the RETURN_ADDRESS macroSergey Bugaev2024-03-231-1/+1
| | | | | | | This gives us PAC stripping on AArch64. Signed-off-by: Sergey Bugaev <bugaevc@gmail.com> Message-ID: <20240323173301.151066-6-bugaevc@gmail.com>
* hurd: Disable Prefer_MAP_32BIT_EXEC on non-x86_64 for nowSergey Bugaev2024-03-232-2/+2
| | | | | | | | While we could support it on any architecture, the tunable is currently only defined on x86_64. Signed-off-by: Sergey Bugaev <bugaevc@gmail.com> Message-ID: <20240323173301.151066-5-bugaevc@gmail.com>
* Implement setcontext/getcontext/makecontext/swapcontext for Hurd x86_64Flavio Cruz2024-02-176-0/+456
| | | | | Tested with the tests provided by glibc plus some other toy examples. Message-ID: <20240217202535.1860803-1-flaviocruz@gmail.com>
* Use proc_getchildren_rusage when available in getrusage and times.Flavio Cruz2024-02-174-3/+216
| | | | Message-ID: <20240217164846.1837223-1-flaviocruz@gmail.com>
* Make __getrandom_nocancel set errno and add a _nostatus versionXi Ruoyao2024-01-121-1/+6
| | | | | | | | | | | | | | | | The __getrandom_nocancel function returns errors as negative values instead of errno. This is inconsistent with other _nocancel functions and it breaks "TEMP_FAILURE_RETRY (__getrandom_nocancel (p, n, 0))" in __arc4random_buf. Use INLINE_SYSCALL_CALL instead of INTERNAL_SYSCALL_CALL to fix this issue. But __getrandom_nocancel has been avoiding from touching errno for a reason, see BZ 29624. So add a __getrandom_nocancel_nostatus function and use it in tcache_key_initialize. Signed-off-by: Xi Ruoyao <xry111@xry111.site> Reviewed-by: Adhemerval Zanella <adhemerval.zanella@linaro.org> Signed-off-by: Andreas K. Hüttel <dilfridge@gentoo.org>
* hurd: Initializy _dl_pagesize early in static buildsSergey Bugaev2024-01-041-0/+4
| | | | | | | | | | | | We fetch __vm_page_size as the very first RPC that we do, inside __mach_init (). Propagate that to _dl_pagesize ASAP after that, before any other initialization. In dynamic builds, this is already done immediately after __mach_init (), inside _dl_sysdep_start (). Signed-off-by: Sergey Bugaev <bugaevc@gmail.com> Message-ID: <20240103171502.1358371-12-bugaevc@gmail.com>
* hurd: Only init early static TLS if it's used to store stack or pointer guardsSergey Bugaev2024-01-041-4/+11
| | | | | | | This is the case on both x86 architectures, but not on AArch64. Signed-off-by: Sergey Bugaev <bugaevc@gmail.com> Message-ID: <20240103171502.1358371-11-bugaevc@gmail.com>
* hurd: Make init-first.c no longer x86-specificSergey Bugaev2024-01-041-2/+2
| | | | | | | This will make it usable in other ports. Signed-off-by: Sergey Bugaev <bugaevc@gmail.com> Message-ID: <20240103171502.1358371-10-bugaevc@gmail.com>
* hurd: Drop x86-specific assembly from init-first.cSergey Bugaev2024-01-041-9/+1
| | | | | | | | We already have the RETURN_TO macro for this exact use case, and it's already used in the non-static code path. Use it here too. Signed-off-by: Sergey Bugaev <bugaevc@gmail.com> Message-ID: <20240103171502.1358371-9-bugaevc@gmail.com>
* hurd: Pass the data pointer to _hurd_stack_setup explicitlySergey Bugaev2024-01-043-9/+11
| | | | | | | | | 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>
* mach: Drop some unnecessary vm_param.h includesSergey Bugaev2024-01-031-1/+0
| | | | Signed-off-by: Sergey Bugaev <bugaevc@gmail.com>
* hurd: Add some missing includesSergey Bugaev2024-01-031-0/+1
| | | | Signed-off-by: Sergey Bugaev <bugaevc@gmail.com>
* Implement C23 <stdbit.h>Joseph Myers2024-01-032-0/+140
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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-01378-378/+378
|
* hurd: [!__USE_MISC] Do not #undef BSD macros in ioctlsSamuel Thibault2023-12-021-0/+2
| | | | | When e.g. including termios.h first and then sys/ioctl.h, without e.g. _BSD_SOURCE, the latter would #undef e.g. ECHO, without defining it.
* Remove __access_noerrnoJoseph Myers2023-11-236-45/+5
| | | | | | | | | | | | | | | | 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.
* hurd: Prevent the final file_exec_paths call from signalsSamuel Thibault2023-11-201-1/+15
| | | | | | | Otherwise if the exec server started thrashing the old task, we won't be able to restart the exec. This notably fixes building ghc.
* hurd: Fix spawni returning allocation errors.Samuel Thibault2023-11-141-2/+8
|
* hurd: statfsconv: Add missing f_ffree conversionSamuel Thibault2023-11-071-0/+1
|
* crypt: Remove libcrypt supportAdhemerval Zanella2023-10-302-9/+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>
* hurd: Drop REG_GSFS and REG_ESDS from x86_64's ucontextSamuel Thibault2023-09-282-9/+3
| | | | These are useless on x86_64, and __NGREG was actually wrong with them.
* htl: avoid exposing the vm_region symbolSamuel Thibault2023-09-091-1/+1
|
* htl: Fix stack information for main threadSamuel Thibault2023-09-031-3/+27
| | | | | We can easily directly ask the kernel with vm_region rather than assuming a one-page stack.
* htl: move pthread_attr_setdetachstate into libcGuy-Fleury Iteriteka2023-08-242-2/+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-242-2/+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-242-2/+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-242-2/+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-242-2/+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-242-2/+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-242-2/+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-242-2/+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-242-2/+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-242-2/+0
| | | | | Signed-off-by: Guy-Fleury Iteriteka <gfleury@disroot.org> Message-Id: <20230716084414.107245-2-gfleury@disroot.org>
* hurd: Make error_t an int in C++Samuel Thibault2023-08-081-0/+6
| | | | | | | Making error_t defined to enum __error_t_codes conveniently makes the debugger print symbolic values, but in C++ int is not interoperable with enum __error_t_codes, leading to C++ application build issues, so let's revert error_t to int in C++.
* hurd: statvfs: __f_type -> f_typeнаб2023-08-081-2/+2
| | | | | | | | | No further changes needed ([f]statvfs() just cast to struct statfs * and call [f]statfs()). Link: https://lore.kernel.org/linux-man/f54kudgblgk643u32tb6at4cd3kkzha6hslahv24szs4raroaz@ogivjbfdaqtb/t/#u Signed-off-by: Ahelenia Ziemiańska <nabijaczleweli@nabijaczleweli.xyz> Reviewed-by: Samuel Thibault <samuel.thibault@ens-lyon.org>
* htl: Initialize ___pthread_self earlySamuel Thibault2023-08-081-0/+14
| | | | | | | | | | When using jemalloc, malloc() needs to use TSD, while libpthread initialization needs malloc(). Having ___pthread_self set early to some static storage allows TSD to work early, thus allowing jemalloc and libpthread to initialize together. This incidentaly simplifies __pthread_enable/disable_asynccancel and __pthread_self, now that ___pthread_self is always initialized.
* hurd: Rework generating errno.hSamuel Thibault2023-08-063-41/+19
| | | | | We only need to give to gawk the headers that actually define error numbers, so let's rather filter out the other included headers early.
* configure: Use autoconf 2.71Siddhesh Poyarekar2023-07-171-11/+14
| | | | | | | | | | | | | | Bump autoconf requirement to 2.71 to allow regenerating configure on more recent distributions. autoconf 2.71 has been in Fedora since F36 and is the current version in Debian stable (bookworm). It appears to be current in Gentoo as well. All sysdeps configure and preconfigure scripts have also been regenerated; all changes are trivial transformations that do not affect functionality. Signed-off-by: Siddhesh Poyarekar <siddhesh@sourceware.org> Reviewed-by: Carlos O'Donell <carlos@redhat.com>
* hurd: Implement MAP_EXCLSergey Bugaev2023-07-032-10/+23
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | MAP_FIXED is defined to silently replace any existing mappings at the address range being mapped over. This, however, is a dangerous, and only rarely desired behavior. Various Unix systems provide replacements or additions to MAP_FIXED: * SerenityOS and Linux provide MAP_FIXED_NOREPLACE. If the address space already contains a mapping in the requested range, Linux returns EEXIST. SerenityOS returns ENOMEM, however that is a bug, as the MAP_FIXED_NOREPLACE implementation is intended to be compatible with Linux. * FreeBSD provides the MAP_EXCL flag that has to be used in combination with MAP_FIXED. It returns EINVAL if the requested range already contains existing mappings. This is directly analogous to the O_EXCL flag in the open () call. * DragonFly BSD, NetBSD, and OpenBSD provide MAP_TRYFIXED, but with different semantics. DragonFly BSD returns ENOMEM if the requested range already contains existing mappings. NetBSD does not return an error, but instead creates the mapping at a different address if the requested range contains mappings. OpenBSD behaves the same, but also notes that this is the default behavior even without MAP_TRYFIXED (which is the case on the Hurd too). Since the Hurd leans closer to the BSD side, add MAP_EXCL as the primary API to request the behavior of not replacing existing mappings. Declare MAP_FIXED_NOREPLACE and MAP_TRYFIXED as aliases of (MAP_FIXED|MAP_EXCL), so any existing software that checks for either of those macros will pick them up automatically. For compatibility with Linux, return EEXIST if a mapping already exists. Signed-off-by: Sergey Bugaev <bugaevc@gmail.com> Message-Id: <20230625231751.404120-5-bugaevc@gmail.com>
* hurd: Fix mapping at address 0 with MAP_FIXEDSergey Bugaev2023-07-031-2/+9
| | | | | | | | | | | Zero address passed to mmap () typically means the caller doesn't have any specific preferred address. Not so if MAP_FIXED is passed: in this case 0 means literal 0. Fix this case to pass anywhere = 0 into vm_map. Also add some documentation. Signed-off-by: Sergey Bugaev <bugaevc@gmail.com> Message-Id: <20230625231751.404120-4-bugaevc@gmail.com>
* hurd: Fix calling vm_deallocate (NULL)Sergey Bugaev2023-07-031-3/+7
| | | | | | | | | | Only call vm_deallocate when we do have the old buffer, and check for unexpected errors. Spotted while debugging a msgids/readdir issue on x86_64-gnu. Signed-off-by: Sergey Bugaev <bugaevc@gmail.com> Message-Id: <20230625231751.404120-3-bugaevc@gmail.com>
* hurd: Map brk non-executableSergey Bugaev2023-07-031-2/+2
| | | | | | | | | | | | The rest of the heap (backed by individual pages) is already mapped RW. Mapping these pages RWX presents a security hazard. Also, in another branch memory gets allocated using vm_allocate, which sets memory protection to VM_PROT_DEFAULT (which is RW). The mismatch between protections prevents Mach from coalescing the VM map entries. Signed-off-by: Sergey Bugaev <bugaevc@gmail.com> Message-Id: <20230625231751.404120-2-bugaevc@gmail.com>
generated by cgit-pink 1.4.1 (git 2.36.1) at 2024-07-01 15:49:45 +0000