musl/crt/crt1.c, branch master musl - an implementation of the standard library for Linux-based systems use hidden visibility for C entry point function _start_c 2024年08月10日T23:49:24+00:00 Rich Felker dalias@aerifal.cx 2024年08月10日T23:49:24+00:00 9c78557af0a5e521cdb46a4ca7630f2987d2523e the file-level crt_arch.h asm fragments generally make direct (non-PLT) calls from _start to _start_c, which is only valid when there is a local, non-interposable definition for _start_c. generally, the linker is expected to know that local definitions in a main executable (as opposed to shared library) output are non-interposable, making this work, but historically there have been linker bugs in this area, and microblaze is reportedly still broken, flagging the relocation for the call as a textrel. the equivalent _dlstart_c, called from the same crt_arch.h asm fragments, has always used hidden visibility without problem, and semantically it should be hidden, so make it hidden. this ensures the direct call is always valid regardless of whether the linker properly special-cases main executable output.
the file-level crt_arch.h asm fragments generally make direct
(non-PLT) calls from _start to _start_c, which is only valid when
there is a local, non-interposable definition for _start_c. generally,
the linker is expected to know that local definitions in a main
executable (as opposed to shared library) output are non-interposable,
making this work, but historically there have been linker bugs in this
area, and microblaze is reportedly still broken, flagging the
relocation for the call as a textrel.
the equivalent _dlstart_c, called from the same crt_arch.h asm
fragments, has always used hidden visibility without problem, and
semantically it should be hidden, so make it hidden. this ensures the
direct call is always valid regardless of whether the linker properly
special-cases main executable output.
remove unnecessary and problematic _Noreturn from crt/ldso startup 2019年06月25日T23:05:40+00:00 Rich Felker dalias@aerifal.cx 2019年06月25日T22:50:05+00:00 54b7564b72c1edcc79fca083047521fb56eaea00 after commit a48ccc159a5fa061a18419296100ee48a1cd6cc9 removed the use of _Noreturn on the stage3_func type (which only worked due to it being defined to the "GNU C" attribute in C99 mode), GCC could no longer assume that the ends of __dls2 and __dls2b are unreachable, and produced a warning that a function marked _Noreturn returns. also, since commit 4390383b32250a941ec616e8bff6f568a801b1c0, the _Noreturn declaration for __libc_start_main in crt1/rcrt1 has been not only inconsistent with the definition, but wrong. formally, __libc_start_main does return, via a (hopefully) tail call to a helper function after the barrier. incorrect usage of _Noreturn in the declaration was probably formal UB. the _Noreturn specifiers were not useful in any of these places, so remove them all. now, the only remaining usage of _Noreturn is in public interfaces where _Noreturn is part of their contract.
after commit a48ccc159a5fa061a18419296100ee48a1cd6cc9 removed the use
of _Noreturn on the stage3_func type (which only worked due to it
being defined to the "GNU C" attribute in C99 mode), GCC could no
longer assume that the ends of __dls2 and __dls2b are unreachable, and
produced a warning that a function marked _Noreturn returns.
also, since commit 4390383b32250a941ec616e8bff6f568a801b1c0, the
_Noreturn declaration for __libc_start_main in crt1/rcrt1 has been not
only inconsistent with the definition, but wrong. formally,
__libc_start_main does return, via a (hopefully) tail call to a helper
function after the barrier. incorrect usage of _Noreturn in the
declaration was probably formal UB.
the _Noreturn specifiers were not useful in any of these places, so
remove them all. now, the only remaining usage of _Noreturn is in
public interfaces where _Noreturn is part of their contract.
define and use internal macros for hidden visibility, weak refs 2018年09月05日T18:05:14+00:00 Rich Felker dalias@aerifal.cx 2018年09月05日T16:43:34+00:00 9b95fd0944e4206949e90633c3fed088202810ec this cleans up what had become widespread direct inline use of "GNU C" style attributes directly in the source, and lowers the barrier to increased use of hidden visibility, which will be useful to recovering some of the efficiency lost when the protected visibility hack was dropped in commit dc2f368e565c37728b0d620380b849c3a1ddd78f, especially on archs where the PLT ABI is costly.
this cleans up what had become widespread direct inline use of "GNU C"
style attributes directly in the source, and lowers the barrier to
increased use of hidden visibility, which will be useful to recovering
some of the efficiency lost when the protected visibility hack was
dropped in commit dc2f368e565c37728b0d620380b849c3a1ddd78f, especially
on archs where the PLT ABI is costly.
dynamic linker bootstrap overhaul 2015年04月13日T07:04:42+00:00 Rich Felker dalias@aerifal.cx 2015年04月13日T06:56:26+00:00 f3ddd173806fd5c60b3f034528ca24542aecc5b9 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.
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.
new mostly-C crt1 implementation 2013年07月26日T05:49:14+00:00 Rich Felker dalias@aerifal.cx 2013年07月26日T05:49:14+00:00 c5e34dabbb47d8e97a4deccbb421e0cd93c0094b 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.
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.
initial check-in, version 0.5.0 2011年02月12日T05:22:29+00:00 Rich Felker dalias@aerifal.cx 2011年02月12日T05:22:29+00:00 0b44a0315b47dd8eced9f3b7f31580cf14bbfc01

AltStyle によって変換されたページ (->オリジナル) /