riscv/musl - musl - Gitea: Git with a cup of tea

3166 Commits

2 Branches

78 Tags

7.6 MiB

Tree: 5fe38516f7

Commit Graph

Author	SHA1	Message	Date
Rich Felker	f3ddd17380	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.	11 years ago
Rich Felker	c5e34dabbb	new mostly-C crt1 implementation the only immediate effect of this commit is enabling PIE support on some archs that did not previously have any Scrt1.s, since the existing asm files for crt1 override this C code. so some of the crt_arch.h files committed are only there for the sake of documenting what their archs "would do" if they used the new C-based crt1. the expectation is that new archs should use this new system rather than using heavy asm for crt1. aside from being easier and less error-prone, it also ensures that PIE support is available immediately (since Scrt1.o is generated from the same C source, using -fPIC) rather than having to be added as an afterthought in the porting process.	13 years ago

Author

SHA1

Message

Date

Rich Felker

f3ddd17380

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.

11 years ago

Rich Felker

c5e34dabbb

new mostly-C crt1 implementation

the only immediate effect of this commit is enabling PIE support on
some archs that did not previously have any Scrt1.s, since the
existing asm files for crt1 override this C code. so some of the
crt_arch.h files committed are only there for the sake of documenting
what their archs "would do" if they used the new C-based crt1.

the expectation is that new archs should use this new system rather
than using heavy asm for crt1. aside from being easier and less
error-prone, it also ensures that PIE support is available immediately
(since Scrt1.o is generated from the same C source, using -fPIC)
rather than having to be added as an afterthought in the porting
process.

13 years ago

2 Commits (5fe38516f7ba0318ab792127bb16621920df3319)