about summary refs log tree commit diff
Commit message (Collapse)AuthorAgeFilesLines
* riscv: Get cache information through sysconfZong Li2020-11-101-0/+100
| | | | | | | | Add support to query cache information on RISC-V through sysconf() function. The cache information had been added in AUX vector of RISC-V architecture in Linux kernel v.5.10-rc1. Reviewed-by: Palmer Dabbelt <palmerdabbelt@google.com> Acked-by: Palmer Dabbelt <palmerdabbelt@google.com>
* RISC-V: Add _dl_start_user.Jim Wilson2020-11-101-1/+3
| | | | | | | | | | | | | This is required for the debugglibc.sh script to work. Tested by successfully using this patched script, and a riscv64-linux testsuite run. We could perhaps call RTLD_EPILOGUE for ENTRY_POINT before calling RTLD_PROLOGUE for _dl_start_user, but I don't think it matters. OK? Jim
* linux: Allow adjtime with NULL argument [BZ #26833]Adhemerval Zanella2020-11-093-4/+54
| | | | | | | | | | | The adjtime interface allows return the amount of time remaining from any previous adjustment that has not yet been completed by passing a NULL as first argument. This was introduced with y2038 support 0308077e3a. Checked on i686-linux-gnu. Reviewed-by: Lukasz Majewski <lukma@denx.de>
* aarch64: Add unwind information to _start (bug 26853)Florian Weimer2020-11-091-4/+3
| | | | | | | This adds CFI directives which communicate that the stack ends with this function. Fixes bug 26853.
* bsd unlockpt: unlockpt needs to fail with EINVAL, not ENOTTYSamuel Thibault2020-11-081-1/+6
| | | | | The EINVAL error code is mandated by POSIX, while ptsname_r returns ENOTTY, so we need to translate.
* Rearrange bsd_getpt vs bsd_openpt and implement posix_openpt on BSDSamuel Thibault2020-11-071-10/+8
| | | | | | | | | * sysdeps/unix/bsd/getpt.c (__getpt): Add oflag parameter, pass it to the _open call and rename to... (__bsd_openpt): ... new function. (__getpt): Reimplement on top of __bsd_openpt. (__posix_openpt): Replace stub with implementation on top of __bsd_openpt. (posix_openpt): Remove stub warning.
* Remove __warndeclSiddhesh Poyarekar2020-11-053-74/+1
| | | | | | The macro is not used anymore, so remove it and warning-nop.c. Reviewed-by: Florian Weimer <fweimer@redhat.com>
* Remove __warn_memset_zero_len [BZ #25399]Siddhesh Poyarekar2020-11-051-15/+0
| | | | | | | | | | | | | | Non-gcc compilers (clang and possibly other compilers that do not masquerade as gcc 5.0 or later) are unable to use __warn_memset_zero_len since the symbol is no longer available on glibc built with gcc 5.0 or later. While it was likely an oversight that caused this omission, the fact that it wasn't noticed until recently (when clang closed the gap on _FORTIFY_SUPPORT) that the symbol was missing. Given that both gcc and clang are capable of doing this check in the compiler, drop all remaining signs of __warn_memset_zero_len from glibc so that no more objects are built with this symbol in future.
* iconv: Accept redundant shift sequences in IBM1364 [BZ #26224]Arjun Shankar2020-11-043-19/+15
| | | | | | | | | | | | | | | The IBM1364, IBM1371, IBM1388, IBM1390 and IBM1399 character sets share converter logic (iconvdata/ibm1364.c) which would reject redundant shift sequences when processing input in these character sets. This led to a hang in the iconv program (CVE-2020-27618). This commit adjusts the converter to ignore redundant shift sequences and adds test cases for iconv_prog hangs that would be triggered upon their rejection. This brings the implementation in line with other converters that also ignore redundant shift sequences (e.g. IBM930 etc., fixed in commit 692de4b3960d). Reviewed-by: Carlos O'Donell <carlos@redhat.com>
* msg: Remove redundant #include <sys/msg.h> headerLukasz Majewski2020-11-046-6/+0
| | | | | | | | | The #include <sys/msg.h> is redundant as we do not use message specific types for issuing syscalls to handle msg and shm. Only msgctl requires this header. Build tests: ./src/scripts/build-many-glibcs.py glibcs
* tst-setuid1-static-ENV: Add $(common-objpfx)nss [BZ #26820]H.J. Lu2020-11-031-1/+1
| | | | | | | | | | | | | | | | | | commit def674652eeac60c386d04733318b311f8a5b620 Author: Florian Weimer <fweimer@redhat.com> Date: Mon Apr 27 15:00:14 2020 +0200 nptl/tst-setuid1-static: Improve isolation from system objects Static dlopen needs an LD_LIBRARY_PATH setting to avoid loading system libraries. missed $(common-objpfx)nss. Add $(common-objpfx)nss to LD_LIBRARY_PATH for tst-setuid1-static to support struct passwd *pwd = getpwnam ("nobody"); in nptl/tst-setuid1.c.
* aarch64: Add variant PCS lazy binding test [BZ #26798]Szabolcs Nagy2020-11-025-0/+288
| | | | | | | | | | | This test fails without bug 26798 fixed because some integer registers likely get clobbered by lazy binding and variant PCS only allows x16 and x17 to be clobbered at call time. The test requires binutils 2.32.1 or newer for handling variant PCS symbols. SVE registers are not covered by this test, to avoid the complexity of handling multiple compile- and runtime feature support cases.
* aarch64: Fix DT_AARCH64_VARIANT_PCS handling [BZ #26798]Szabolcs Nagy2020-11-021-8/+4
| | | | | | | | | | | | | The variant PCS support was ineffective because in the common case linkmap->l_mach.plt == 0 but then the symbol table flags were ignored and normal lazy binding was used instead of resolving the relocs early. (This was a misunderstanding about how GOT[1] is setup by the linker.) In practice this mainly affects SVE calls when the vector length is more than 128 bits, then the top bits of the argument registers get clobbered during lazy binding. Fixes bug 26798.
* hurd: Correct 'ethenet' spellingJonny Grant2020-10-311-1/+1
| | | | Signed-off-by: Jonny Grant <jg@jguk.org>
* Avoid -Wstringop-overflow warning in pthread_cleanup_push macrosJoseph Myers2020-10-302-10/+35
| | | | | | | | | | | | | | | | | | | | | GCC 11 introduces a -Wstringop-overflow warning for calls to functions with an array argument passed as a pointer to memory not large enough for that array. This includes the __sigsetjmp calls from pthread_cleanup_push macros, because those use a structure in __pthread_unwind_buf_t, which has a common initial subsequence with jmp_buf but does not include the saved signal mask; this is OK in this case because the second argument to __sigsetjmp is 0 so the signal mask is not accessed. To avoid this warning, use a function alias __sigsetjmp_cancel with first argument an array of exactly the type used in the calls to the function, if using GCC 11 or later. With older compilers, continue to use __sigsetjmp with a cast, to avoid any issues with compilers predating the returns_twice attribute not applying the same special handling to __sigsetjmp_cancel as to __sigsetjmp. Tested with build-many-glibcs.py for arm-linux-gnueabi that this fixes the testsuite build failures.
* Disable spurious -Warray-bounds for ypclnt.c (bug 26687)Joseph Myers2020-10-301-0/+8
| | | | | | | | | | | | | | | | | Included among the GCC 11 warnings listed in bug 26687, but not fixed when that bug was marked as FIXED, are -Warray-bounds warnings in nis/ypclnt.c. These are all for different calls to the same piece of code, which already has a comment explaining that the element accessed is in a common prefix of the various structures. On the basis of that comment, this patch treats the warning as a false positive and disables it for that code. Tested with build-many-glibcs.py for arm-linux-gnueabi, where, together with my previous two patches, this allows the build of glibc to complete with GCC 11 (further build failures appear in the testsuite). Reviewed-by: DJ Delorie <dj@redhat.com>
* Do not use array parameter to new_composite_name (bug 26726)Joseph Myers2020-10-301-1/+1
| | | | | | | | | | | | | | Among the warnings causing a glibc build with GCC 11 to fail is one for a call new_composite_name in setlocale.c. The newnames argument is declared as an array with __LC_LAST elements, but when the category argument is not LC_ALL, it actually only has one element. Since the number of elements depends on the first argument to the function, it seems clearer to declare the argument as a pointer. Tested with build-many-glibcs.py for arm-linux-gnueabi, where this allows the build to get further. Reviewed-by: DJ Delorie <dj@redhat.com>
* Disable spurious -Wstringop-overflow for setjmp/longjmp (bug 26647)Joseph Myers2020-10-303-0/+30
| | | | | | | | | | | | | | | | | Building glibc with GCC 11 fails with (among other warnings) spurious -Wstringop-overflow warnings from calls to setjmp and longjmp with a pointer to a pthread_unwind_buf that is smaller than jmp_buf. As discussed in bug 26647, the warning in libc-start.c is a false positive, because setjmp and longjmp do not access anything (the signal mask) beyond the common prefix of the two structures, so this patch disables the warning for that call to setjmp, as well as for two calls in NPTL code that produce the same warning and look like false positives for the same reason. Tested with build-many-glibcs.py for arm-linux-gnueabi, where this allows the build to get further. Reviewed-by: DJ Delorie <dj@redhat.com>
* malloc debug: fix compile error when enable macro MALLOC_DEBUG > 1liqingqing2020-10-301-2/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | malloc debug: fix compile error when enable macro MALLOC_DEBUG > 1. this is because commit e9c4fe93b3855239752819303ca377dff0ed0553 has change the struct malloc_chunk's member "size" to "mchunk_size". the reproduction is like that: setp1: modify related Makefile. vim ../glibc/malloc/Makefile CPPFLAGS-malloc.o += -DMALLOC_DEBUG=2 step2: ../configure --prefix=/usr make -j32 this will cause the compile error: /home/liqingqing/glibc_upstream/buildglibc/malloc/malloc.o In file included from malloc.c:1899:0: arena.c: In function 'dump_heap': arena.c:422:58: error: 'struct malloc_chunk' has no member named 'size' fprintf (stderr, "chunk %p size %10lx", p, (long) p->size); ^~ arena.c:428:17: error: 'struct malloc_chunk' has no member named 'size' else if (p->size == (0 | PREV_INUSE)) Reviewed-by: DJ Delorie <dj@redhat.com>
* tst-tcfree2: adjust coding style.liqingqing2020-10-301-4/+4
| | | | | | tst-tcfree2: adjust coding style. Reviewed-by: DJ Delorie <dj@redhat.com>
* elf: In ldconfig, extract the new_sub_entry function from search_dirFlorian Weimer2020-10-301-13/+21
| | | | Reviewed-by: Adhemerval Zanella <adhemerval.zanella@linaro.org>
* Use MPC 1.2.1 in build-many-glibcs.py.Joseph Myers2020-10-301-1/+1
| | | | | | | This patch makes build-many-glibcs.py use the new MPC 1.2.1 release. Tested with build-many-glibcs.py (host-libraries, compilers and glibcs builds).
* Argument Syntax: Use "option", @option, and @command.Carlos O'Donell2020-10-301-6/+6
| | | | Suggested-by: David O'Brien <daobrien@redhat.com>
* elf: Unify old and new format cache handling code in ld.soFlorian Weimer2020-10-302-146/+158
| | | | | | | struct file_entry_new starts with the fields of struct file_entry, so the code can be shared if the size computation is made dynamic. Reviewed-by: Adhemerval Zanella <adhemerval.zanella@linaro.org>
* x86: Restore processing of cache size tunables in init_cacheinfoFlorian Weimer2020-10-281-8/+4
| | | | | Fixes and partially reverts commit 59803e81f96b479c17f583b31eac44b5 ("x86: Optimizing memcpy for AMD Zen architecture.").
* Make elf.h header self contained.Érico Rolim2020-10-281-6/+0
| | | | | | | | | | | | The elf/elf.h header is shared, verbatim, by the elfutils project. However, elfutils can be used on systems with libcs other than glibc, making the presence of __BEGIN_DECLS, __END_DECLS and <features.h> in the file something that downstream distros may have to add patches for. Furthermore, this file doesn't declare anything with language linkage, so `extern "C" {}` blocks aren't necessary; it also doesn't have any conditional definitions based on feature test macros, making inclusion of features.h unnecessary.
* x86: Optimizing memcpy for AMD Zen architecture.Sajan Karumanchi2020-10-281-6/+26
| | | | | | | | | | | | | | Modifying the shareable cache '__x86_shared_cache_size', which is a factor in computing the non-temporal threshold parameter '__x86_shared_non_temporal_threshold' to optimize memcpy for AMD Zen architectures. In the existing implementation, the shareable cache is computed as 'L3 per thread, L2 per core'. Recomputing this shareable cache as 'L3 per CCX(Core-Complex)' has brought in performance gains. As per the large bench variant results, this patch also addresses the regression problem on AMD Zen architectures. Reviewed-by: Premachandra Mallappa <premachandra.mallappa@amd.com>
* Hurd: Fix ftime buildAdhemerval Zanella2020-10-272-25/+58
| | | | | | | | It does not provide __clock_gettime64, the ftime y2038 support is moved to a Linux specific implementation. Checked with a build for i686-linux-gnu and on x86_64-linux and i686-linux-gnu.
* Add IP_RECVERR_RFC4884 and IPV6_RECVERR_RFC4884 from Linux 5.9.Joseph Myers2020-10-271-0/+2
| | | | | | | Add the new constants IP_RECVERR_RFC4884 and IPV6_RECVERR_RFC4884 from Linux 5.9 to bits/in.h. Tested for x86_64.
* misc: Add internal __getauxval2 functionFlorian Weimer2020-10-272-6/+32
| | | | | | | | The explicit error return value (without in-band signaling) avoids complicated steps to detect errors based on whether errno has been updated. Reviewed-by: Alistair Francis <alistair.francis@wdc.com>
* Remove NEWS entry about ftime removalAdhemerval Zanella2020-10-271-5/+0
| | | | Now that it was reinstate with 30a0b167d3.
* time: Add 64-bit time_t support for ftimeAdhemerval Zanella2020-10-277-16/+70
| | | | | | | | | It basically calls the 64-bit __clock_gettime64 and adds the overflow check. Checked on x86_64-linux-gnu and i686-linux-gnu. Reviewed-by: Lukasz Majewski <lukma@denx.de>
* Reinstate ftime and add deprecate message on ftime usageAdhemerval Zanella2020-10-276-45/+65
| | | | | | | This patch revert "Move ftime to a compatibility symbol" (commit 14633d3e568eb9770a7e5046eff257113e0453fb). Checked on x86_64-linux-gnu and i686-linux-gnu.
* Update kernel version to 5.9 in tst-mman-consts.py.Joseph Myers2020-10-261-1/+1
| | | | | | | | This patch updates the kernel version in the test tst-mman-consts.py to 5.9. (There are no new MAP_* constants covered by this test in 5.9 that need any other header changes.) Tested with build-many-glibcs.py.
* Amend grammar and add a descriptionJonny Grant2020-10-261-3/+4
| | | | Reviewed-by: Carlos O'Donell <carlos@redhat.com>
* Fix typo in NEWS fileJonathan Wakely2020-10-261-1/+1
|
* Remove timing related checks of time/tst-cpuclock1Stefan Liebler2020-10-261-59/+6
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Starting with the commit 04deeaa9ea74b0679dfc9d9155a37b6425f19a9f "Fix time/tst-cpuclock1 intermitent failures" (2020-07-11), this test fails quite often on s390x/s390 with one/multiple of those: "before - after" / "nanosleep time" / "dead - after" ourside reasonable range. On a zVM/kvm guest the CPUs are shared between multiple guests. And even on the lpar (kvm host) the CPUs are usually shared between multiple lpars. The defined CPUs for a lpar/zVM-system could also have lower weights compared to other lpars which let the steal time further grow. Usually I build (-j$(nproc)) and test (PARALLELMFLAGS="-j$(nproc)") glibc multiple times, e.g. with different GCCs, on various lpars or zVM guests at the same time. During this time, I've run the test for 13500 times and obvserved the following fails: ~600x "before - after" ~60x "nanosleep time" ~70x "dead - after" I've also observed a lot of "before - after" fails on a intel kvm-guest while building/testing glibc on it. The mentioned commit has tighten the limits of valid tv_nsec ranges: "before - after" (expected: 500000000): - 100000000 ... 600000000 + 450000000 ... 550000000 "nanosleep time" (expected: 100000000): - 100000000 ... 200000000 + 090000000 ... 120000000 "dead - after" (expected: 100000000): - ... 200000000 + 090000000 ... 120000000 The test itself forks a child process which chew_cpu (user- and kernel-space). The parent process sleeps with nanosleep(0.5s) and measures the child_clock time: diff = after - before With much workload on the machine, the child won't make much progess and it can fall much beyond the minimum limit. Afterwards the parent process sleeps with clock_nanosleep (child_clock, 0.1s): diff = afterns - after The test currently also allows 0.9 * 0.1s which would be an error. Depending on the workload, the maximum limit can exceed the 1.2 * 0.1s. For "dead - after", the parent process kills the child process and waits long enough to let the child finish dying. Then it gets the time of the child: diff = dead - after Note that diff also contains the time for the previous clock_nanosleep. Thus you'll often see both fails at the same time. After discussion on the mailing list, we've decided to keep the functional checks for the clock* functions and remove the timing related checks as those are prone to false positives. Reviewed-by: Adhemerval Zanella <adhemerval.zanella@linaro.org> Reviewed-by: Carlos O'Donell <carlos@redhat.com>
* Update syscall lists for Linux 5.9.Joseph Myers2020-10-2326-2/+28
| | | | | | | | Linux 5.9 has one new syscall, close_range. Update syscall-names.list and regenerate the arch-syscall.h headers with build-many-glibcs.py update-syscalls. Tested with build-many-glibcs.py.
* Use Linux 5.9 in build-many-glibcs.py.Joseph Myers2020-10-221-1/+1
| | | | | | | This patch makes build-many-glibcs.py use Linux 5.9. Tested with build-many-glibcs.py (host-libraries, compilers and glibcs builds).
* Reword description of SXID_* tunable propertiesSiddhesh Poyarekar2020-10-222-10/+12
| | | | | | | | | | | | | The SXID_* tunable properties only influence processes that are AT_SECURE, so make that a bit more explicit in the documentation and comment. Revisiting the code after a few years I managed to confuse myself, so I imagine there could be others who may have incorrectly assumed like I did that the SXID_ERASE tunables are not inherited by children of non-AT_SECURE processes. Reviewed-by: Florian Weimer <fweimer@redhat.com>
* New benchtest: pthread locksDJ Delorie2020-10-212-1/+556
| | | | | | | | Performance benchmarks for various posix locks: mutex, rwlock, spinlock, condvar, and semaphore. Each test is performed with an empty loop body or with a computationally "interesting" (i.e. difficult to optimize away, and used just to allow lock code to be "hidden" in the filler's CPU cycles).
* y2038: nptl: Provide __futex_clock_wait_bitset64 to support 64 bit bitsetLukasz Majewski2020-10-213-2/+53
| | | | | | | | | | | | | | | The commit: "y2038: nptl: Convert pthread_mutex_{clock|timed}lock to support 64 bit" SHA1: 29e9874a048f47e2d46c40253036c8d2de921548 introduced support for 64 bit timeouts. Unfortunately, it was missing the code for bitset - i.e. lll_futex_clock_wait_bitset C preprocessor macro was used. As a result the 64 bit struct __timespec64 was coerced to 32 bit struct timespec and regression visible as timeout was observed (nptl/tst-robust10 on s390). Reported-by: Stefan Liebler <stli@linux.ibm.com> Tested-by: Stefan Liebler <stli@linux.ibm.com>
* C-SKY: Make dynamic linker's name compitable with the older gcc.Cooper Qu2020-10-211-9/+26
| | | | | | | | | | | | | | __CSKY_HARD_FLOAT_ABI__ was added on gcc 11 to specify whether -mfloat-abi=hard is set. On older gcc, the float ABI is defined solely with __CSKY_HARD_FLOAT__. If __CSKY_HARD_FLOAT__ is set, it can be either a hard-float ABI (gcc older than 11, or gcc11 -mfloat-abi=hard (__CSKY_HARD_FLOAT_ABI__ is set) or -mfloat-abi=softfp (__CSKY_HARD_FLOAT_ABI__ is not set). To be compatible with older gcc, use __CSKY_HARD_FLOAT_FPU_SF__ identify if -mfloat-abi is supported, because it is added to gcc at the same time as -mfloat-abi. Reviewed-by: Mao Han <han_mao@linux.alibaba.com> Reviewed-by: Adhemerval Zanella  <adhemerval.zanella@linaro.org>
* Revert "C-SKY:Fix dynamic linker's name when mfloat-abi=softfp."Mao Han2020-10-201-1/+1
| | | | This reverts commit 7449320983b664aba506d7674ea0ce142dd3d4ed.
* Move vtimes to a compatibility symbolAdhemerval Zanella2020-10-197-135/+48
| | | | | | | | | | | | | | I couldn't pinpoint which standard has added it, but no other POSIX system supports it and/or no longer provide it. The 'struct vtimes' also has a lot of drawbacks due its limited internal type size. I couldn't also see find any project that actually uses this symbol, either in some dignostic way (such as sanitizer). So I think it should be safer to just move to compat symbol, instead of deprecated. The idea it to avoid new ports to export such broken interface (riscv32 for instance). Checked on x86_64-linux-gnu and i686-linux-gnu.
* y2038: linux: Provide __time64 implementationLukasz Majewski2020-10-194-3/+50
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | In the glibc the time function can use vDSO (on power and x86 the USE_IFUNC_TIME is defined), time syscall or 'default' time() from ./time/time.c (as a fallback). In this patch the last function (time) has been refactored and moved to ./sysdeps/unix/sysv/linux/time.c to be Linux specific. The new __time64 explicit 64 bit function for providing 64 bit value of seconds after epoch (by internally calling __clock_gettime64) has been introduced. Moreover, a 32 bit version - __time has been refactored to internally use __time64. The __time is now supposed to be used on systems still supporting 32 bit time (__TIMESIZE != 64) - hence the necessary check for time_t potential overflow. The iFUNC vDSO direct call optimization has been removed from both i686 and powerpc32 (USE_IFUNC_TIME is not defined for those architectures anymore). The Linux kernel does not provide a y2038 safe implementation of time neither it plans to provide it in the future, __clock_gettime64 should be used instead. Keeping support for this optimization would require to handle another build permutation (!__ASSUME_TIME64_SYSCALLS && USE_IFUNC_TIME which adds more complexity and has limited use (since the idea is to eventually have a y2038 safe glibc build). Build tests: ./src/scripts/build-many-glibcs.py glibcs Run-time tests: - Run specific tests on ARM/x86 32bit systems (qemu): https://github.com/lmajewski/meta-y2038 and run tests: https://github.com/lmajewski/y2038-tests/commits/master Above tests were performed with Y2038 redirection applied as well as without to test proper usage of both __time64 and __time. Reviewed-by: Adhemerval Zanella <adhemerval.zanella@linaro.org>
* rt: Fix typos in comments in <aio.h>Jonny Grant2020-10-191-7/+6
|
* C-SKY:Fix dynamic linker's name when mfloat-abi=softfp.Cooper Qu2020-10-191-1/+1
| | | | | | | | The dynamic linker should be chosen according to float abi, the predefined macro __CSKY_HARD_FLOAT__ stand for architecure not abi. Reviewed-by: Mao Han <han_mao@linux.alibaba.com>
* x86: Initialize CPU info via IFUNC relocation [BZ 26203]H.J. Lu2020-10-169-865/+949
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | X86 CPU features in ld.so are initialized by init_cpu_features, which is invoked by DL_PLATFORM_INIT from _dl_sysdep_start. But when ld.so is loaded by static executable, DL_PLATFORM_INIT is never called. Also x86 cache info in libc.o and libc.a is initialized by a constructor which may be called too late. Since some fields in _rtld_global_ro in ld.so are initialized by dynamic relocation, we can also initialize x86 CPU features in _rtld_global_ro in ld.so and cache info in libc.so by initializing dummy function pointers in ld.so and libc.so via IFUNC relocation. Key points: 1. IFUNC is always supported, independent of --enable-multi-arch or --disable-multi-arch. Linker generates IFUNC relocations from input IFUNC objects and ld.so performs IFUNC relocations. 2. There are no IFUNC dependencies in ld.so before dynamic relocation have been performed, 3. The x86 CPU features in ld.so is initialized by DL_PLATFORM_INIT in dynamic executable and by IFUNC relocation in dlopen in static executable. 4. The x86 cache info in libc.o is initialized by IFUNC relocation. 5. In libc.a, both x86 CPU features and cache info are initialized from ARCH_INIT_CPU_FEATURES, not by IFUNC relocation, before __libc_early_init is called. Note: _dl_x86_init_cpu_features can be called more than once from DL_PLATFORM_INIT and during relocation in ld.so.
* Add NEWS entry for ftime compatibility moveAdhemerval Zanella2020-10-161-0/+5
|
generated by cgit-pink 1.4.1 (git 2.36.1) at 2024-11-09 05:08:11 +0000