- 29 1月, 2023 1 次提交
-
-
由 dhy308 提交于
Issue: I6A9R5 Test: libc-test pass Signed-off-by: Ndhy308 <tony.gan@huawei.com>
-
- 12 1月, 2023 1 次提交
-
-
由 dhy308 提交于
Issue: I6A9R5 Test: libc-test pass Signed-off-by: Ndhy308 <tony.gan@huawei.com>
-
- 18 11月, 2022 1 次提交
-
-
由 dhy308 提交于
描述:依据android+relr格式,在重定位阶段进行解析处理 Issue:https://gitee.com/openharmony/build/issues/I61B4G? 测试:开机测试、应用启动正常 Signed-off-by: Ndhy308 <tony.gan@huawei.com>
-
- 05 8月, 2022 1 次提交
-
-
由 ganlan 提交于
Signed-off-by: Nganlan <tony.gan@huawei.com>
-
- 11 1月, 2022 1 次提交
-
-
由 caifuzhou 提交于
Signed-off-by: Ncaifuzhou <caifuzhou@huawei.com>
-
- 11 3月, 2021 1 次提交
-
-
由 mamingshuai 提交于
-
- 09 9月, 2020 1 次提交
-
-
由 wenjun 提交于
-
- 01 1月, 2020 1 次提交
-
-
由 Rich Felker 提交于
this interface contract is entirely internal to dynlink.c.
-
- 12 8月, 2019 1 次提交
-
-
由 Samuel Holland 提交于
R_PPC_UADDR32 (R_PPC64_UADDR64) has the same meaning as R_PPC_ADDR32 (R_PPC64_ADDR64), except that its address need not be aligned. For powerpc64, BFD ld(1) will automatically convert between ADDR<->UADDR relocations when the address is/isn't at its native alignment. This will happen if, for example, there is a pointer in a packed struct. gold and lld do not currently generate R_PPC64_UADDR64, but pass through misaligned R_PPC64_ADDR64 relocations from object files, possibly relaxing them to misaligned R_PPC64_RELATIVE. In both cases (relaxed or not) this violates the PSABI, which defines the relevant field type as "a 64-bit field occupying 8 bytes, the alignment of which is 8 bytes unless otherwise specified." All three linkers violate the PSABI on 32-bit powerpc, where the only difference is that the field is 32 bits wide, aligned to 4 bytes. Currently musl fails to load executables linked by BFD ld containing R_PPC64_UADDR64, with the error "unsupported relocation type 43". This change provides compatibility with BFD ld on powerpc64, and any static linker on either architecture that starts following the PSABI more closely.
-
- 22 6月, 2019 1 次提交
-
-
由 Matthew Maurer 提交于
_Noreturn is a C11 construct, and may only be used at the site of a function definition.
-
- 13 9月, 2018 2 次提交
-
-
由 Rich Felker 提交于
libc.h was intended to be a header for access to global libc state and related interfaces, but ended up included all over the place because it was the way to get the weak_alias macro. most of the inclusions removed here are places where weak_alias was needed. a few were recently introduced for hidden. some go all the way back to when libc.h defined CANCELPT_BEGIN and _END, and all (wrongly implemented) cancellation points had to include it. remaining spurious users are mostly callers of the LOCK/UNLOCK macros and files that use the LFS64 macro to define the awful *64 aliases. in a few places, new inclusion of libc.h is added because several internal headers no longer implicitly include libc.h. declarations for __lockfile and __unlockfile are moved from libc.h to stdio_impl.h so that the latter does not need libc.h. putting them in libc.h made no sense at all, since the macros in stdio_impl.h are needed to use them correctly anyway.
-
由 Rich Felker 提交于
-
- 07 3月, 2016 1 次提交
-
-
由 Rich Felker 提交于
this change is made in preparation for adding the mips64 port, which needs a 64-bit (and mips64-specific) form of the R_INFO macro, but it's a better abstraction anyway. based on part of the mips64 port patch by Mahesh Bodapati and Jaydeep Patil of Imagination Technologies.
-
- 31 1月, 2016 1 次提交
-
-
由 Felix Fietkau 提交于
GDB is looking for a pointer to the ldso debug info in the data of the ..rld_map section. Signed-off-by: NFelix Fietkau <nbd@openwrt.org>
-
- 12 11月, 2015 1 次提交
-
-
由 Rich Felker 提交于
on linux/nommu, non-writable private mappings of files may actually use memory shared with other processes or the fs cache. the old nommu loader code (used when mmap with MAP_FIXED fails) simply wrote over top of the original file mapping, possibly clobbering this shared memory. no such breakage was observed in practice, but it should have been possible. the new code starts by mapping anonymous writable memory on archs that might support nommu, then maps load segments over top of it, falling back to read if MAP_FIXED fails. we use an anonymous map rather than a writable file map to avoid reading more data from disk than needed. since pages cannot be loaded lazily on fault, in case of large data/bss, mapping the full file may read a lot of data that will subsequently be thrown away when processing additional LOAD segments. as a result, we cannot skip the first LOAD segment when operating in this mode. these changes affect only non-FDPIC nommu support.
-
- 23 9月, 2015 1 次提交
-
-
由 Rich Felker 提交于
previously, the normal ELF library loading code was used even for fdpic, so only the kernel-loaded dynamic linker and main app could benefit from separate placement of segments and shared text.
-
- 22 9月, 2015 1 次提交
-
-
由 Rich Felker 提交于
at this point not all functionality is complete. the dynamic linker itself, and main app if it is also loaded by the kernel, take advantage of fdpic and do not need constant displacement between segments, but additional libraries loaded by the dynamic linker follow normal ELF semantics for mapping still. this fully works, but does not admit shared text on nommu. in terms of actual functional correctness, dlsym's results are presently incorrect for function symbols, RTLD_NEXT fails to identify the caller correctly, and dladdr fails almost entirely. with the dynamic linker entry point working, support for static pie is automatically included, but linking the main application as ET_DYN (pie) probably does not make sense for fdpic anyway. ET_EXEC is equally relocatable but more efficient at representing relocations.
-
- 18 9月, 2015 1 次提交
-
-
由 Rich Felker 提交于
-
- 26 5月, 2015 1 次提交
-
-
由 Rich Felker 提交于
this move eliminates a duplicate "by-hand" symbol lookup loop from the stage-1 code and replaces it with a call to find_sym, which can be used once we're in stage 2. it reduces the size of the stage 1 code, which is helpful because stage 1 will become the crt start file for static-PIE executables, and it will allow stage 3 to access stage 2's automatic storage, which will be important in an upcoming commit.
-
- 13 4月, 2015 1 次提交
-
-
由 Rich Felker 提交于
this overhaul further reduces the amount of arch-specific code needed by the dynamic linker and removes a number of assumptions, including: - that symbolic function references inside libc are bound at link time via the linker option -Bsymbolic-functions. - that libc functions used by the dynamic linker do not require access to data symbols. - that static/internal function calls and data accesses can be made without performing any relocations, or that arch-specific startup code handled any such relocations needed. removing these assumptions paves the way for allowing libc.so itself to be built with stack protector (among other things), and is achieved by a three-stage bootstrap process: 1. relative relocations are processed with a flat function. 2. symbolic relocations are processed with no external calls/data. 3. main program and dependency libs are processed with a fully-functional libc/ldso. reduction in arch-specific code is achived through the following: - crt_arch.h, used for generating crt1.o, now provides the entry point for the dynamic linker too. - asm is no longer responsible for skipping the beginning of argv[] when ldso is invoked as a command. - the functionality previously provided by __reloc_self for heavily GOT-dependent RISC archs is now the arch-agnostic stage-1. - arch-specific relocation type codes are mapped directly as macros rather than via an inline translation function/switch statement.
-