about summary refs log tree commit diff
path: root/sysdeps/i386
Commit message (Collapse)AuthorAgeFilesLines
* math: Fix i386 and m68k exp10 on static build (BZ 31775)Adhemerval Zanella2024-07-021-2/+7
| | | | | | | | | | | | The commit 08ddd26814 removed the static exp10 on i386 and m68k with an empty w_exp10.c (required for the ABIs that uses the newly implementation). This patch fixes by adding the required symbols on the arch-specific w_exp{f}_compat.c implementation. Checked on i686-linux-gnu and with a build for m68k-linux-gnu. Reviewed-by: Aurelien Jarno <aurelien@aurel32.net> (cherry picked from commit 1f09aae36aa185b8b1100dfa6b776442279bf580)
* math: Fix i386 and m68k fmod/fmodf on static build (BZ 31488)Adhemerval Zanella2024-07-022-6/+8
| | | | | | | | | | | | | | | | The commit 16439f419b removed the static fmod/fmodf on i386 and m68k with and empty w_fmod.c (required for the ABIs that uses the newly implementation). This patch fixes by adding the required symbols on the arch-specific w_fmod{f}_compat.c implementation. To statically build fmod fails on some ABI (alpha, s390, sparc) because it does not export the ldexpf128, this is also fixed by this patch. Checked on i686-linux-gnu and with a build for m68k-linux-gnu. Reviewed-by: Aurelien Jarno <aurelien@aurel32.net> Tested-by: Aurelien Jarno <aurelien@aurel32.net> (cherry picked from commit 0b716305dfb48c2d13ed4f7d06c082b90c1d226f)
* i686: Fix multiple definitions of __memmove_chk and __memset_chkGabi Falk2024-05-042-2/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | Commit c73c96a4a1af1326df7f96eec58209e1e04066d8 updated memcpy.S and mempcpy.S, but omitted memmove.S and memset.S. As a result, the static library built as PIC, whether with or without multiarch support, contains two definitions for each of the __memmove_chk and __memset_chk symbols. /usr/lib/gcc/i686-pc-linux-gnu/14/../../../../i686-pc-linux-gnu/bin/ld: /usr/lib/gcc/i686-pc-linux-gnu/14/../../../../lib/libc.a(memset-ia32.o): in function `__memset_chk': /var/tmp/portage/sys-libs/glibc-2.39-r3/work/glibc-2.39/string/../sysdeps/i386/i686/memset.S:32: multiple definition of `__memset_chk'; /usr/lib/gcc/i686-pc-linux-gnu/14/../../../../lib/libc.a(memset_chk.o):/var/tmp/portage/sys-libs/glibc-2.39-r3/work/glibc-2.39/debug/../sysdeps/i386/i686/multiarch/memset_chk.c:24: first defined here After this change, regardless of PIC options, the static library, built for i686 with multiarch contains implementations of these functions respectively from debug/memmove_chk.c and debug/memset_chk.c, and without multiarch contains implementations of these functions respectively from sysdeps/i386/memmove_chk.S and sysdeps/i386/memset_chk.S. This ensures that memmove and memset won't pull in __chk_fail and the routines it calls. Reported-by: Sam James <sam@gentoo.org> Tested-by: Sam James <sam@gentoo.org> Fixes: c73c96a4a1 ("i686: Fix build with --disable-multiarch") Signed-off-by: Gabi Falk <gabifalk@gmx.com> Reviewed-by: H.J. Lu <hjl.tools@gmail.com> Reviewed-by: Dmitry V. Levin <ldv@altlinux.org> (cherry picked from commit 5a2cf833f5772d6c37c7adac388dd9af9cc1c4b9)
* i586: Fix multiple definitions of __memcpy_chk and __mempcpy_chkGabi Falk2024-05-041-1/+1
| | | | | | | | | | | | | | | | | /home/bmg/install/compilers/x86_64-linux-gnu/lib/gcc/x86_64-glibc-linux-gnu/13.2.1/../../../../x86_64-glibc-linux-gnu/bin/ld: /home/bmg/build/glibcs/i586-linux-gnu/glibc/libc.a(memcpy_chk.o): in function `__memcpy_chk': /home/bmg/src/glibc/debug/../sysdeps/i386/memcpy_chk.S:29: multiple definition of `__memcpy_chk';/home/bmg/build/glibcs/i586-linux-gnu/glibc/libc.a(memcpy.o):/home/bmg/src/glibc/string/../sysdeps/i386/i586/memcpy.S:31: first defined here /home/bmg/install/compilers/x86_64-linux-gnu/lib/gcc/x86_64-glibc-linux-gnu/13.2.1/../../../../x86_64-glibc-linux-gnu/bin/ld: /home/bmg/build/glibcs/i586-linux-gnu/glibc/libc.a(mempcpy_chk.o): in function `__mempcpy_chk': /home/bmg/src/glibc/debug/../sysdeps/i386/mempcpy_chk.S:28: multiple definition of `__mempcpy_chk'; /home/bmg/build/glibcs/i586-linux-gnu/glibc/libc.a(mempcpy.o):/home/bmg/src/glibc/string/../sysdeps/i386/i586/memcpy.S:31: first defined here After this change, the static library built for i586, regardless of PIC options, contains implementations of these functions respectively from sysdeps/i386/memcpy_chk.S and sysdeps/i386/mempcpy_chk.S. This ensures that memcpy and mempcpy won't pull in __chk_fail and the routines it calls. Reported-by: Florian Weimer <fweimer@redhat.com> Signed-off-by: Gabi Falk <gabifalk@gmx.com> Reviewed-by: H.J. Lu <hjl.tools@gmail.com> Reviewed-by: Dmitry V. Levin <ldv@altlinux.org> (cherry picked from commit 0fdf4ba48ccce5abf567340b0ab8fa8ed8a9bc6e)
* Revert "i586: Fix multiple definitions of __memcpy_chk and __mempcpy_chk"Sam James2024-05-041-1/+1
| | | | | | | | | | This reverts commit 3148714ab61ad61281bae5a30f530d637034ac3b. I had the wrong cherry-pick reference (the commit content is right; it's just referring to a base that isn't upstream), but let's revert and reapply for clarity. Signed-off-by: Sam James <sam@gentoo.org>
* Revert "i686: Fix multiple definitions of __memmove_chk and __memset_chk"Sam James2024-05-042-2/+2
| | | | | | | | | | This reverts commit ad92c483a4bd34db1cfb3eb625212ea64848244f. I had the wrong cherry-pick reference (the commit content is right; it's just referring to a base that isn't upstream), but let's revert and reapply for clarity. Signed-off-by: Sam James <sam@gentoo.org>
* i686: Fix multiple definitions of __memmove_chk and __memset_chkGabi Falk2024-05-042-2/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | Commit c73c96a4a1af1326df7f96eec58209e1e04066d8 updated memcpy.S and mempcpy.S, but omitted memmove.S and memset.S. As a result, the static library built as PIC, whether with or without multiarch support, contains two definitions for each of the __memmove_chk and __memset_chk symbols. /usr/lib/gcc/i686-pc-linux-gnu/14/../../../../i686-pc-linux-gnu/bin/ld: /usr/lib/gcc/i686-pc-linux-gnu/14/../../../../lib/libc.a(memset-ia32.o): in function `__memset_chk': /var/tmp/portage/sys-libs/glibc-2.39-r3/work/glibc-2.39/string/../sysdeps/i386/i686/memset.S:32: multiple definition of `__memset_chk'; /usr/lib/gcc/i686-pc-linux-gnu/14/../../../../lib/libc.a(memset_chk.o):/var/tmp/portage/sys-libs/glibc-2.39-r3/work/glibc-2.39/debug/../sysdeps/i386/i686/multiarch/memset_chk.c:24: first defined here After this change, regardless of PIC options, the static library, built for i686 with multiarch contains implementations of these functions respectively from debug/memmove_chk.c and debug/memset_chk.c, and without multiarch contains implementations of these functions respectively from sysdeps/i386/memmove_chk.S and sysdeps/i386/memset_chk.S. This ensures that memmove and memset won't pull in __chk_fail and the routines it calls. Reported-by: Sam James <sam@gentoo.org> Tested-by: Sam James <sam@gentoo.org> Fixes: c73c96a4a1 ("i686: Fix build with --disable-multiarch") Signed-off-by: Gabi Falk <gabifalk@gmx.com> Reviewed-by: H.J. Lu <hjl.tools@gmail.com> Reviewed-by: Dmitry V. Levin <ldv@altlinux.org> (cherry picked from commit 5a2cf833f5772d6c37c7adac388dd9af9cc1c4b9)
* i586: Fix multiple definitions of __memcpy_chk and __mempcpy_chkGabi Falk2024-05-041-1/+1
| | | | | | | | | | | | | | | | | /home/bmg/install/compilers/x86_64-linux-gnu/lib/gcc/x86_64-glibc-linux-gnu/13.2.1/../../../../x86_64-glibc-linux-gnu/bin/ld: /home/bmg/build/glibcs/i586-linux-gnu/glibc/libc.a(memcpy_chk.o): in function `__memcpy_chk': /home/bmg/src/glibc/debug/../sysdeps/i386/memcpy_chk.S:29: multiple definition of `__memcpy_chk';/home/bmg/build/glibcs/i586-linux-gnu/glibc/libc.a(memcpy.o):/home/bmg/src/glibc/string/../sysdeps/i386/i586/memcpy.S:31: first defined here /home/bmg/install/compilers/x86_64-linux-gnu/lib/gcc/x86_64-glibc-linux-gnu/13.2.1/../../../../x86_64-glibc-linux-gnu/bin/ld: /home/bmg/build/glibcs/i586-linux-gnu/glibc/libc.a(mempcpy_chk.o): in function `__mempcpy_chk': /home/bmg/src/glibc/debug/../sysdeps/i386/mempcpy_chk.S:28: multiple definition of `__mempcpy_chk'; /home/bmg/build/glibcs/i586-linux-gnu/glibc/libc.a(mempcpy.o):/home/bmg/src/glibc/string/../sysdeps/i386/i586/memcpy.S:31: first defined here After this change, the static library built for i586, regardless of PIC options, contains implementations of these functions respectively from sysdeps/i386/memcpy_chk.S and sysdeps/i386/mempcpy_chk.S. This ensures that memcpy and mempcpy won't pull in __chk_fail and the routines it calls. Reported-by: Florian Weimer <fweimer@redhat.com> Signed-off-by: Gabi Falk <gabifalk@gmx.com> Reviewed-by: H.J. Lu <hjl.tools@gmail.com> Reviewed-by: Dmitry V. Levin <ldv@altlinux.org> (cherry picked from commit 789894a2f554d4503ecb2f13b2b4e93e43414f33)
* i386: ulp update for SSE2 --disable-multi-arch configurationsFlorian Weimer2024-04-251-0/+1
| | | | (cherry picked from commit 3a3a4497421422aa854c855cbe5110ca7d598ffc)
* i386: Use generic memrchr in libc (bug 31316)Florian Weimer2024-04-072-1/+1
| | | | | | | | | Before this change, we incorrectly used the SSE2 variant in the implementation, without checking that the system actually supports SSE2. Tested-by: Sam James <sam@gentoo.org> (cherry picked from commit 0d9166c2245cad4ac520b337dee40c9a583872b6)
* x86: Update _dl_tlsdesc_dynamic to preserve caller-saved registersH.J. Lu2024-04-013-66/+241
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | Compiler generates the following instruction sequence for GNU2 dynamic TLS access: leaq tls_var@TLSDESC(%rip), %rax call *tls_var@TLSCALL(%rax) or leal tls_var@TLSDESC(%ebx), %eax call *tls_var@TLSCALL(%eax) CALL instruction is transparent to compiler which assumes all registers, except for EFLAGS and RAX/EAX, are unchanged after CALL. When _dl_tlsdesc_dynamic is called, it calls __tls_get_addr on the slow path. __tls_get_addr is a normal function which doesn't preserve any caller-saved registers. _dl_tlsdesc_dynamic saved and restored integer caller-saved registers, but didn't preserve any other caller-saved registers. Add _dl_tlsdesc_dynamic IFUNC functions for FNSAVE, FXSAVE, XSAVE and XSAVEC to save and restore all caller-saved registers. This fixes BZ #31372. Add GLRO(dl_x86_64_runtime_resolve) with GLRO(dl_x86_tlsdesc_dynamic) to optimize elf_machine_runtime_setup. Reviewed-by: Noah Goldstein <goldstein.w.n@gmail.com> (cherry picked from commit 0aac205a814a8511e98d02b91a8dc908f1c53cde)
* math: remove exp10 wrappersWilco Dijkstra2024-01-121-0/+3
| | | | | | | | Remove the error handling wrapper from exp10. This is very similar to the changes done to exp and exp2, except that we also need to handle pow10 and pow10l. Reviewed-by: Adhemerval Zanella <adhemerval.zanella@linaro.org>
* i386: Remove CET support bitsH.J. Lu2024-01-102-78/+2
| | | | | | | | | | | | 1. Remove _dl_runtime_resolve_shstk and _dl_runtime_profile_shstk. 2. Move CET offsets from x86 cpu-features-offsets.sym to x86-64 features-offsets.sym. 3. Rename x86 cet-control.h to x86-64 feature-control.h since it is only for x86-64 and also used for PLT rewrite. 4. Add x86-64 ldsodefs.h to include feature-control.h. 5. Change TUNABLE_CALLBACK (set_plt_rewrite) to x86-64 only. 6. Move x86 dl-procruntime.c to x86-64. Reviewed-by: Adhemerval Zanella <adhemerval.zanella@linaro.org>
* i386: Fail if configured with --enable-cetAdhemerval Zanella2024-01-092-7/+8
| | | | | | Since it is only supported for x86_64. Checked on i686-linux-gnu.
* i386: Remove CET supportAdhemerval Zanella2024-01-0921-241/+29
| | | | | | | | | | | | | | | | | | | | | | | | | | CET is only support for x86_64, this patch reverts: - faaee1f07ed x86: Support shadow stack pointer in setjmp/longjmp. - be9ccd27c09 i386: Add _CET_ENDBR to indirect jump targets in add_n.S/sub_n.S - c02695d7764 x86/CET: Update vfork to prevent child return - 5d844e1b725 i386: Enable CET support in ucontext functions - 124bcde683 x86: Add _CET_ENDBR to functions in crti.S - 562837c002 x86: Add _CET_ENDBR to functions in dl-tlsdesc.S - f753fa7dea x86: Support IBT and SHSTK in Intel CET [BZ #21598] - 825b58f3fb i386-mcount.S: Add _CET_ENDBR to _mcount and __fentry__ - 7e119cd582 i386: Use _CET_NOTRACK in i686/memcmp.S - 177824e232 i386: Use _CET_NOTRACK in memcmp-sse4.S - 0a899af097 i386: Use _CET_NOTRACK in memcpy-ssse3-rep.S - 7fb613361c i386: Use _CET_NOTRACK in memcpy-ssse3.S - 77a8ae0948 i386: Use _CET_NOTRACK in memset-sse2-rep.S - 00e7b76a8f i386: Use _CET_NOTRACK in memset-sse2.S - 90d15dc577 i386: Use _CET_NOTRACK in strcat-sse2.S - f1574581c7 i386: Use _CET_NOTRACK in strcpy-sse2.S - 4031d7484a i386/sub_n.S: Add a missing _CET_ENDBR to indirect jump - target - Checked on i686-linux-gnu.
* i386: Ignore --enable-cetH.J. Lu2024-01-042-0/+9
| | | | | | | | | | | | | | Since shadow stack is only supported for x86-64, ignore --enable-cet for i386. Always setting $(enable-cet) for i386 to "no" to support ifneq ($(enable-cet),no) in x86 Makefiles. We can't use ifeq ($(enable-cet),yes) since $(enable-cet) can be "yes", "no" or "permissive". Reviewed-by: Adhemerval Zanella <adhemerval.zanella@linaro.org>
* Update copyright dates with scripts/update-copyrightsPaul Eggert2024-01-01275-275/+275
|
* x86: Do not raises floating-point exception traps on fesetexceptflag (BZ 30990)Bruno Haible2023-12-191-21/+42
| | | | | | | | | | | | | | | | | | | According to ISO C23 (7.6.4.4), fesetexcept is supposed to set floating-point exception flags without raising a trap (unlike feraiseexcept, which is supposed to raise a trap if feenableexcept was called with the appropriate argument). The flags can be set in the 387 unit or in the SSE unit. When we need to clear a flag, we need to do so in both units, due to the way fetestexcept is implemented. When we need to set a flag, it is sufficient to do it in the SSE unit, because that is guaranteed to not trap. However, on i386 CPUs that have only a 387 unit, set the flags in the 387, as long as this cannot trap. Co-authored-by: Adhemerval Zanella <adhemerval.zanella@linaro.org> Reviewed-by: Carlos O'Donell <carlos@redhat.com>
* i686: Do not raise exception traps on fesetexcept (BZ 30989)Adhemerval Zanella2023-12-192-4/+71
| | | | | | | | | | | | | | | | According to ISO C23 (7.6.4.4), fesetexcept is supposed to set floating-point exception flags without raising a trap (unlike feraiseexcept, which is supposed to raise a trap if feenableexcept was called with the appropriate argument). The flags can be set in the 387 unit or in the SSE unit. To set a flag, it is sufficient to do it in the SSE unit, because that is guaranteed to not trap. However, on i386 CPUs that have only a 387 unit, set the flags in the 387, as long as this cannot trap. Checked on i686-linux-gnu. Reviewed-by: Carlos O'Donell <carlos@redhat.com>
* elf: Remove LD_PROFILE for static binariesAdhemerval Zanella2023-11-212-1/+3
| | | | | | | | | | | The _dl_non_dynamic_init does not parse LD_PROFILE, which does not enable profile for dlopen objects. Since dlopen is deprecated for static objects, it is better to remove the support. It also allows to trim down libc.a of profile support. Checked on x86_64-linux-gnu. Reviewed-by: Siddhesh Poyarekar <siddhesh@sourceware.org>
* x86: Use dl-symbol-redir-ifunc.h on cpu-tunablesAdhemerval Zanella2023-11-211-0/+5
| | | | | | | | | | | | | | | | The dl-symbol-redir-ifunc.h redirects compiler-generated libcalls to arch-specific memory implementations to avoid ifunc calls where it is not yet possible. The memcmp-isa-default-impl.h aims to fix the same issue by calling the specific memset implementation directly. Using the memcmp symbol directly allows the compiler to inline the memset calls (especially because _dl_tunable_set_hwcaps uses constants values), generating better code. Checked on x86_64-linux-gnu. Reviewed-by: Noah Goldstein <goldstein.w.n@gmail.com> Reviewed-by: Siddhesh Poyarekar <siddhesh@sourceware.org>
* i686: Fix build with --disable-multiarchAdhemerval Zanella2023-08-106-2/+10
| | | | | | | | | | | | | | Since i686 provides the fortified wrappers for memcpy, mempcpy, memmove, and memset on the same string implementation, the static build tries to optimized it by not tying the fortified wrappers to string routine (to avoid pulling the fortify function if they are not required). Checked on i686-linux-gnu building with different option: default and --disable-multi-arch plus default, --disable-default-pie, --enable-fortify-source={2,3}, and --enable-fortify-source={2,3} with --disable-default-pie. Reviewed-by: Siddhesh Poyarekar <siddhesh@sourceware.org>
* i386: Remove memset_chk-nonshared.SAdhemerval Zanella Netto2023-07-264-30/+6
| | | | | | | | | Similar to memcpy, mempcpy, and memmove there is no need for an specific memset_chk-nonshared.S. It can be provided by memset-ia32.S itself for static library. Checked on i686-linux-gnu. Reviewed-by: Carlos O'Donell <carlos@redhat.com>
* i386: Fix build with --enable-fortify=3Adhemerval Zanella Netto2023-07-264-65/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The i386 string routines provide multiple internal definitions for memcpy, memmove, and mempcpy chk routines: $ objdump -t libc.a | grep __memcpy_chk 00000000 g F .text 0000000e __memcpy_chk 00000000 g F .text 00000013 __memcpy_chk $ objdump -t libc.a | grep __mempcpy_chk 00000000 g F .text 0000000e __mempcpy_chk 00000000 g F .text 00000013 __mempcpy_chk $ objdump -t libc.a | grep __memmove_chk 00000000 g F .text 0000000e __memmove_chk 00000000 g F .text 00000013 __memmove_chk Although is not an issue for normal static builds, with fortify=3 glibc itself might use the fortify chk functions and thus static build might fail with multiple definitions. For instance: x86_64-glibc-linux-gnu-gcc -m32 -march=i686 -o [...]math/test-signgam-uchar-static -nostdlib -nostartfiles -static -static-pie [...] x86_64-glibc-linux-gnu/bin/ld: [...]/libc.a(mempcpy-ia32.o): in function `__mempcpy_chk': [...]/glibc-git/string/../sysdeps/i386/i686/mempcpy.S:32: multiple definition of `__mempcpy_chk'; [...]/libc.a(mempcpy_chk-nonshared.o):[...]/debug/../sysdeps/i386/mempcpy_chk.S:28: first defined here collect2: error: ld returned 1 exit status make[2]: *** [../Rules:298: There is no need for mem*-nonshared.S, the __mem*_chk routines are already provided by the assembly routines. Checked on i686-linux-gnu with gcc 13 built with fortify=1,2,3 and without fortify. Reviewed-by: Carlos O'Donell <carlos@redhat.com>
* Update i686 libm-test-ulps (again)Andreas K. Hüttel2023-07-191-1/+1
| | | | | | | | Based on feedback by Arsen Arsenović <arsen@gentoo.org> Linux-6.1.38-gentoo-dist-hardened x86_64 AMD Ryzen 7 3800X 8-Core Processor -march=x86-64-v2 Signed-off-by: Andreas K. Hüttel <dilfridge@gentoo.org>
* Update i686 libm-test-ulpsAndreas K. Hüttel2023-07-181-0/+1
| | | | Signed-off-by: Andreas K. Hüttel <dilfridge@gentoo.org>
* configure: Use autoconf 2.71Siddhesh Poyarekar2023-07-171-14/+16
| | | | | | | | | | | | | | 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>
* i386: make debug wrappers compatible with static PIEAndreas Schwab2023-07-124-8/+8
| | | | Static PIE requires the use of PLT relocation.
* sysdeps: Add missing hidden definitions for i386Frédéric Bérat2023-07-102-0/+2
| | | | | Add missing libc_hidden_builtin_def for memset_chk and MEMCPY_CHK on i386.
* string: Ensure *_chk routines have their hidden builtin definition availableFrédéric Bérat2023-07-0514-1/+26
| | | | | | | If libc_hidden_builtin_{def,proto} isn't properly set for *_chk routines, there are unwanted PLT entries in libc.so. Reviewed-by: Siddhesh Poyarekar <siddhesh@sourceware.org>
* sysdeps/{i386, x86_64}/mempcpy_chk.S: fix linknamespace for __mempcpy_chkFrederic Berat2023-06-221-1/+1
| | | | | | | | | | | | | On i386 and x86_64, for libc.a specifically, __mempcpy_chk calls mempcpy which leads POSIX routines to call non-POSIX mempcpy indirectly. This leads the linknamespace test to fail when glibc is built with __FORTIFY_SOURCE=3. Since calling mempcpy doesn't bring any benefit for libc.a, directly call __mempcpy instead. Reviewed-by: Siddhesh Poyarekar <siddhesh@sourceware.org>
* Fix misspellings in sysdeps/ -- BZ 25337Paul Pluzhnikov2023-05-306-6/+6
|
* math: Remove the error handling wrapper from fmod and fmodfAdhemerval Zanella Netto2023-04-032-0/+28
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The error handling is moved to sysdeps/ieee754 version with no SVID support. The compatibility symbol versions still use the wrapper with SVID error handling around the new code. There is no new symbol version nor compatibility code on !LIBM_SVID_COMPAT targets (e.g. riscv). The ia64 is unchanged, since it still uses the arch specific __libm_error_region on its implementation. For both i686 and m68k, which provive arch specific implementation, wrappers are added so no new symbol are added (which would require to change the implementations). It shows an small improvement, the results for fmod: Architecture | Input | master | patch -----------------|-----------------|----------|-------- x86_64 (Ryzen 9) | subnormals | 12.5049 | 9.40992 x86_64 (Ryzen 9) | normal | 296.939 | 296.738 x86_64 (Ryzen 9) | close-exponents | 16.0244 | 13.119 aarch64 (N1) | subnormal | 6.81778 | 4.33313 aarch64 (N1) | normal | 155.620 | 152.915 aarch64 (N1) | close-exponents | 8.21306 | 5.76138 armhf (N1) | subnormal | 15.1083 | 14.5746 armhf (N1) | normal | 244.833 | 241.738 armhf (N1) | close-exponents | 21.8182 | 22.457 Checked on x86_64-linux-gnu, i686-linux-gnu, and aarch64-linux-gnu. Reviewed-by: Wilco Dijkstra <Wilco.Dijkstra@arm.com>
* hurd: Move rtld-strncpy-c.c out of mach/hurd/Sergey Bugaev2023-04-031-0/+1
| | | | | | | | 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>
* htl: Generalize i386 pt-machdep.h to x86Samuel Thibault2023-02-122-28/+1
|
* string: Add libc_hidden_proto for memrchrAdhemerval Zanella2023-02-082-0/+3
| | | | | | | Although static linker can optimize it to local call, it follows the internal scheme to provide hidden proto and definitions. Reviewed-by: Carlos Eduardo Seo <carlos.seo@linaro.org>
* string: Add libc_hidden_proto for strchrnulAdhemerval Zanella2023-02-081-0/+1
| | | | | | | Although static linker can optimize it to local call, it follows the internal scheme to provide hidden proto and definitions. Reviewed-by: Carlos Eduardo Seo <carlos.seo@linaro.org>
* string: Improve generic strnlen with memchrAdhemerval Zanella2023-02-061-7/+7
| | | | | | | | It also cleanups the multiple inclusion by leaving the ifunc implementation to undef the weak_alias and libc_hidden_def. Co-authored-by: Richard Henderson <richard.henderson@linaro.org> Reviewed-by: Noah Goldstein <goldstein.w.n@gmail.com>
* Parameterize OP_T_THRES from memcopy.hRichard Henderson2023-02-062-3/+25
| | | | | | | | | | | | It moves OP_T_THRES out of memcopy.h to its own header and adjust each architecture that redefines it. Checked with a build and check with run-built-tests=no for all major Linux ABIs. Co-authored-by: Adhemerval Zanella <adhemerval.zanella@linaro.org> Reviewed-by: Carlos O'Donell <carlos@redhat.com> Reviewed-by: Richard Henderson <richard.henderson@linaro.org>
* Update copyright dates with scripts/update-copyrightsJoseph Myers2023-01-06278-278/+278
|
* i686: Regenerate ulpsAndreas K. Hüttel2023-01-021-7/+7
| | | | Reviewed-by: Florian Weimer <fweimer@redhat.com>
* i386: Avoid rely on linker optimization to avoid relocationAdhemerval Zanella Netto2022-11-211-4/+9
| | | | | | | | | | | | | | lld does not implement all the linker optimization to avoid the GOT relocation as done by binutils (bfd/elf32-i386.c:elf_i386_convert_load_reloc). The current 'movl main@GOT(%ebx), %eax' will then create a GOT relocation when building with lld, which make static-pie status to not being able to start the provided main function. The change uses a __wrap_main local symbol, which in turn calls main (similar as used by aarch64 and s390x). Checked on i686-linux-gnu with binutils and lld. Reviewed-by: Fangrui Song <maskray@google.com>
* elf: Introduce <dl-call_tls_init_tp.h> and call_tls_init_tp (bug 29249)Florian Weimer2022-11-031-2/+1
| | | | | | | | This makes it more likely that the compiler can compute the strlen argument in _startup_fatal at compile time, which is required to avoid a dependency on strlen this early during process startup. Reviewed-by: Szabolcs Nagy <szabolcs.nagy@arm.com>
* Remove all assembly optimizations for htonl and htonsAdhemerval Zanella2022-10-241-35/+0
| | | | | | | | | | The builtin bswap is already used if optimziation is enabled for GCC 4.8+, so glibc symbols will be used in a very limited scenarios. Also, gcc generated code is quite similar to all but ia64 and i386 htons. Checked on alpha, i686, and ia64.
* Remove htonl.S for i386/x86_64Cristian Rodríguez2022-10-241-34/+0
| | | | | | | Generic implementation on top of __bswap_32 always expands inline to either bswap or movbe depending on -march=*. Signed-off-by: Cristian Rodríguez <crrodriguez@opensuse.org>
* Use PTR_MANGLE and PTR_DEMANGLE unconditionally in C sourcesFlorian Weimer2022-10-182-7/+1
| | | | | | | | | | | | | | | | | In the future, this will result in a compilation failure if the macros are unexpectedly undefined (due to header inclusion ordering or header inclusion missing altogether). Assembler sources are more difficult to convert. In many cases, they are hand-optimized for the mangling and no-mangling variants, which is why they are not converted. sysdeps/s390/s390-32/__longjmp.c and sysdeps/s390/s390-64/__longjmp.c are special: These are C sources, but most of the implementation is in assembler, so the PTR_DEMANGLE macro has to be undefined in some cases, to match the assembler style. Reviewed-by: Adhemerval Zanella <adhemerval.zanella@linaro.org>
* Introduce <pointer_guard.h>, extracted from <sysdep.h>Florian Weimer2022-10-185-0/+5
| | | | | | | | | | | | | | This allows us to define a generic no-op version of PTR_MANGLE and PTR_DEMANGLE. In the future, we can use PTR_MANGLE and PTR_DEMANGLE unconditionally in C sources, avoiding an unintended loss of hardening due to missing include files or unlucky header inclusion ordering. In i386 and x86_64, we can avoid a <tls.h> dependency in the C code by using the computed constant from <tcb-offsets.h>. <sysdep.h> no longer includes these definitions, so there is no cyclic dependency anymore when computing the <tcb-offsets.h> constants. Reviewed-by: Adhemerval Zanella <adhemerval.zanella@linaro.org>
* elf: Remove -fno-tree-loop-distribute-patterns usage on dl-supportAdhemerval Zanella2022-10-101-0/+24
| | | | | | | | | | | | | | Besides the option being gcc specific, this approach is still fragile and not future proof since we do not know if this will be the only optimization option gcc will add that transforms loops to memset (or any libcall). This patch adds a new header, dl-symbol-redir-ifunc.h, that can b used to redirect the compiler generated libcalls to port the generic memset implementation if required. Checked on x86_64-linux-gnu and aarch64-linux-gnu. Reviewed-by: Carlos O'Donell <carlos@redhat.com>
* x86: Remove .tfloat usageAdhemerval Zanella2022-10-038-25/+45
| | | | | Some compiler does not support it (such as clang integrated assembler) neither gcc emits it.
* i386: Use cmpl instead of cmpAdhemerval Zanella2022-08-052-12/+12
| | | | Clang cannot assemble cmp in the AT&T dialect mode.
generated by cgit-pink 1.4.1 (git 2.36.1) at 2024-09-03 09:24:22 +0000