fluencelabs/musl
1
0
Fork 0
mirror of https://github.com/fluencelabs/musl synced 2025-04-30 17:42:14 +00:00
Code Issues Projects Releases Wiki Activity
musl/arch/sh/crt_arch.h

56 lines
978 B
C
Raw Normal View History

add fdpic version of entry point code for sh this version of the entry point is only suitable for static linking in ET_EXEC form. neither dynamic linking nor pie is supported yet. at some point in the future the fdpic and non-fdpic versions of this code may be unified but for now it's easiest to work with them separately.
2015-09-12 03:18:08 +00:00
#ifdef __SH_FDPIC__
__asm__(
".text \n"
".global " START " \n"
START ": \n"
" mov r8, r4 \n"
" mova 1f, r0 \n"
" mov.l 1f, r5 \n"
" mov.l 1f+4, r6 \n"
" add r0, r5 \n"
" bsr __fdpic_fixup \n"
" add r0, r6 \n"
" mov r0, r12 \n"
add general fdpic support in dynamic linker and arch support for sh 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.
2015-09-22 03:54:42 +00:00
" mov r10, r5 \n"
add fdpic version of entry point code for sh this version of the entry point is only suitable for static linking in ET_EXEC form. neither dynamic linking nor pie is supported yet. at some point in the future the fdpic and non-fdpic versions of this code may be unified but for now it's easiest to work with them separately.
2015-09-12 03:18:08 +00:00
" mov r15, r4 \n"
add general fdpic support in dynamic linker and arch support for sh 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.
2015-09-22 03:54:42 +00:00
" mov.l r9, @-r15 \n"
" mov.l r8, @-r15 \n"
add fdpic version of entry point code for sh this version of the entry point is only suitable for static linking in ET_EXEC form. neither dynamic linking nor pie is supported yet. at some point in the future the fdpic and non-fdpic versions of this code may be unified but for now it's easiest to work with them separately.
2015-09-12 03:18:08 +00:00
" mov #-16, r0 \n"
" bsr " START "_c \n"
" and r0, r15 \n"
".align 2 \n"
"1: .long __ROFIXUP_LIST__@PCREL \n"
" .long __ROFIXUP_END__@PCREL + 4 \n"
);
#include "fdpic_crt.h"
#else
dynamic linker bootstrap overhaul 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.
2015-04-13 02:56:26 -04:00
__asm__(
add .text section directive to all crt_arch.h files missing it i386 and x86_64 versions already had the .text directive; other archs did not. normally, top-level (file scope) __asm__ starts in the .text section anyway, but problems were reported with some versions of clang, and it seems preferable to set it explicitly anyway, at least for the sake of consistency between archs.
2015-05-22 01:50:05 -04:00
".text \n"
dynamic linker bootstrap overhaul 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.
2015-04-13 02:56:26 -04:00
".global " START " \n"
START ": \n"
" mova 1f, r0 \n"
" mov.l 1f, r5 \n"
" add r0, r5 \n"
" mov r15, r4 \n"
" mov #-16, r0 \n"
" and r0, r15 \n"
" bsr " START "_c \n"
" nop \n"
".align 2 \n"
".weak _DYNAMIC \n"
".hidden _DYNAMIC \n"
"1: .long _DYNAMIC-. \n"
);
superh: fix dynamic linking of __fpscr_values Applications ended up with copy relocations for this array, which resulted in libc's references to this array pointing to the application's copy. The dynamic linker, however, can require this array before the application is relocated, and therefore before the application's copy of this array is initialized. This resulted in garbage being loaded into FPSCR before executing main, which violated the ABI. We fix this by putting the array in crt1 and making the libc copy private. This prevents libc's reference to the array from pointing to an uninitialized copy in the application.
2014-03-16 16:17:28 -05:00
add fdpic version of entry point code for sh this version of the entry point is only suitable for static linking in ET_EXEC form. neither dynamic linking nor pie is supported yet. at some point in the future the fdpic and non-fdpic versions of this code may be unified but for now it's easiest to work with them separately.
2015-09-12 03:18:08 +00:00
#endif
superh: fix dynamic linking of __fpscr_values Applications ended up with copy relocations for this array, which resulted in libc's references to this array pointing to the application's copy. The dynamic linker, however, can require this array before the application is relocated, and therefore before the application's copy of this array is initialized. This resulted in garbage being loaded into FPSCR before executing main, which violated the ABI. We fix this by putting the array in crt1 and making the libc copy private. This prevents libc's reference to the array from pointing to an uninitialized copy in the application.
2014-03-16 16:17:28 -05:00
/* used by gcc for switching the FPU between single and double precision */
dynamic linker bootstrap overhaul 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.
2015-04-13 02:56:26 -04:00
#ifdef SHARED
__attribute__((__visibility__("hidden")))
#endif
superh: fix dynamic linking of __fpscr_values Applications ended up with copy relocations for this array, which resulted in libc's references to this array pointing to the application's copy. The dynamic linker, however, can require this array before the application is relocated, and therefore before the application's copy of this array is initialized. This resulted in garbage being loaded into FPSCR before executing main, which violated the ABI. We fix this by putting the array in crt1 and making the libc copy private. This prevents libc's reference to the array from pointing to an uninitialized copy in the application.
2014-03-16 16:17:28 -05:00
const unsigned long __fpscr_values[2] = { 0, 0x80000 };
Reference in New Issue Copy Permalink