|
|
|
|
#include <elf.h>
|
|
|
|
|
#include <poll.h>
|
|
|
|
|
#include <fcntl.h>
|
|
|
|
|
#include <signal.h>
|
|
|
|
|
#include "syscall.h"
|
|
|
|
|
#include "atomic.h"
|
|
|
|
|
#include "libc.h"
|
|
|
|
|
|
|
|
|
|
void __init_tls(size_t *);
|
|
|
|
|
|
remove undef weak refs to init/fini array symbols in libc.so
commit ad1cd43a86645ba2d4f7c8747240452a349d6bc1 eliminated
preprocessor-level omission of references to the init/fini array
symbols from object files going into libc.so. the references are weak,
and the intent was that the linker would resolve them to zero in
libc.so, but instead it leaves undefined references that could be
satisfied at runtime. normally these references would be harmless,
since the code using them does not even get executed, but some older
binutils versions produce a linking error: when linking a program
against libc.so, ld first tries to use the hidden init/fini array
symbols produced by the linker script to satisfy the references in
libc.so, then produces an error because the definitions are hidden.
ideally ld would have already provided definitions of these symbols
when linking libc.so, but the linker script for -shared omits them.
to avoid this situation, the dynamic linker now provides its own dummy
definitions of the init/fini array symbols for libc.so. since they are
hidden, everything binds at ld time and no references remain in the
dynamic symbol table. with modern binutils and --gc-sections, both
the dummy empty array objects and the code referencing them get
dropped at link time, anyway.
the _init and _fini symbols are also switched back to using weak
definitions rather than weak references since the latter behave
somewhat problematically in general, and the weak definition approach
was known to work well.
11 years ago
|
|
|
static void dummy(void) {}
|
|
|
|
|
weak_alias(dummy, _init);
|
|
|
|
|
|
|
|
|
|
__attribute__((__weak__, __visibility__("hidden")))
|
|
|
|
|
extern void (*const __init_array_start)(void), (*const __init_array_end)(void);
|
add support for init/fini array in main program, and greatly simplify
modern (4.7.x and later) gcc uses init/fini arrays, rather than the
legacy _init/_fini function pasting and crtbegin/crtend ctors/dtors
system, on most or all archs. some archs had already switched a long
time ago. without following this change, global ctors/dtors will cease
to work under musl when building with new gcc versions.
the most surprising part of this patch is that it actually reduces the
size of the init code, for both static and shared libc. this is
achieved by (1) unifying the handling main program and shared
libraries in the dynamic linker, and (2) eliminating the
glibc-inspired rube goldberg machine for passing around init and fini
function pointers. to clarify, some background:
the function signature for __libc_start_main was based on glibc, as
part of the original goal of being able to run some glibc-linked
binaries. it worked by having the crt1 code, which is linked into
every application, static or dynamic, obtain and pass pointers to the
init and fini functions, which __libc_start_main is then responsible
for using and recording for later use, as necessary. however, in
neither the static-linked nor dynamic-linked case do we actually need
crt1.o's help. with dynamic linking, all the pointers are available in
the _DYNAMIC block. with static linking, it's safe to simply access
the _init/_fini and __init_array_start, etc. symbols directly.
obviously changing the __libc_start_main function signature in an
incompatible way would break both old musl-linked programs and
glibc-linked programs, so let's not do that. instead, the function can
just ignore the information it doesn't need. new archs need not even
provide the useless args in their versions of crt1.o. existing archs
should continue to provide it as long as there is an interest in
having newly-linked applications be able to run on old versions of
musl; at some point in the future, this support can be removed.
13 years ago
|
|
|
|
|
|
|
|
static void dummy1(void *p) {}
|
|
|
|
|
weak_alias(dummy1, __init_ssp);
|
|
|
|
|
|
|
|
|
|
#define AUX_CNT 38
|
|
|
|
|
|
|
|
|
|
void __init_libc(char **envp, char *pn)
|
|
|
|
|
{
|
|
|
|
|
size_t i, *auxv, aux[AUX_CNT] = { 0 };
|
|
|
|
|
__environ = envp;
|
|
|
|
|
for (i=0; envp[i]; i++);
|
|
|
|
|
libc.auxv = auxv = (void *)(envp+i+1);
|
|
|
|
|
for (i=0; auxv[i]; i+=2) if (auxv[i]<AUX_CNT) aux[auxv[i]] = auxv[i+1];
|
|
|
|
|
__hwcap = aux[AT_HWCAP];
|
|
|
|
|
__sysinfo = aux[AT_SYSINFO];
|
|
|
|
|
libc.page_size = aux[AT_PAGESZ];
|
|
|
|
|
|
|
|
|
|
if (!pn) pn = (void*)aux[AT_EXECFN];
|
|
|
|
|
if (!pn) pn = "";
|
|
|
|
|
__progname = __progname_full = pn;
|
|
|
|
|
for (i=0; pn[i]; i++) if (pn[i]=='/') __progname = pn+i+1;
|
|
|
|
|
|
|
|
|
|
__init_tls(aux);
|
|
|
|
|
__init_ssp((void *)aux[AT_RANDOM]);
|
|
|
|
|
|
|
|
|
|
if (aux[AT_UID]==aux[AT_EUID] && aux[AT_GID]==aux[AT_EGID]
|
|
|
|
|
&& !aux[AT_SECURE]) return;
|
|
|
|
|
|
|
|
|
|
struct pollfd pfd[3] = { {.fd=0}, {.fd=1}, {.fd=2} };
|
|
|
|
|
#ifdef SYS_poll
|
|
|
|
|
__syscall(SYS_poll, pfd, 3, 0);
|
|
|
|
|
#else
|
|
|
|
|
__syscall(SYS_ppoll, pfd, 3, &(struct timespec){0}, 0, _NSIG/8);
|
|
|
|
|
#endif
|
|
|
|
|
for (i=0; i<3; i++) if (pfd[i].revents&POLLNVAL)
|
|
|
|
|
if (__sys_open("/dev/null", O_RDWR)<0)
|
|
|
|
|
a_crash();
|
|
|
|
|
libc.secure = 1;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
static void libc_start_init(void)
|
|
|
|
|
{
|
remove undef weak refs to init/fini array symbols in libc.so
commit ad1cd43a86645ba2d4f7c8747240452a349d6bc1 eliminated
preprocessor-level omission of references to the init/fini array
symbols from object files going into libc.so. the references are weak,
and the intent was that the linker would resolve them to zero in
libc.so, but instead it leaves undefined references that could be
satisfied at runtime. normally these references would be harmless,
since the code using them does not even get executed, but some older
binutils versions produce a linking error: when linking a program
against libc.so, ld first tries to use the hidden init/fini array
symbols produced by the linker script to satisfy the references in
libc.so, then produces an error because the definitions are hidden.
ideally ld would have already provided definitions of these symbols
when linking libc.so, but the linker script for -shared omits them.
to avoid this situation, the dynamic linker now provides its own dummy
definitions of the init/fini array symbols for libc.so. since they are
hidden, everything binds at ld time and no references remain in the
dynamic symbol table. with modern binutils and --gc-sections, both
the dummy empty array objects and the code referencing them get
dropped at link time, anyway.
the _init and _fini symbols are also switched back to using weak
definitions rather than weak references since the latter behave
somewhat problematically in general, and the weak definition approach
was known to work well.
11 years ago
|
|
|
_init();
|
|
|
|
|
uintptr_t a = (uintptr_t)&__init_array_start;
|
|
|
|
|
for (; a<(uintptr_t)&__init_array_end; a+=sizeof(void(*)()))
|
|
|
|
|
(*(void (**)(void))a)();
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
weak_alias(libc_start_init, __libc_start_init);
|
|
|
|
|
|
add support for init/fini array in main program, and greatly simplify
modern (4.7.x and later) gcc uses init/fini arrays, rather than the
legacy _init/_fini function pasting and crtbegin/crtend ctors/dtors
system, on most or all archs. some archs had already switched a long
time ago. without following this change, global ctors/dtors will cease
to work under musl when building with new gcc versions.
the most surprising part of this patch is that it actually reduces the
size of the init code, for both static and shared libc. this is
achieved by (1) unifying the handling main program and shared
libraries in the dynamic linker, and (2) eliminating the
glibc-inspired rube goldberg machine for passing around init and fini
function pointers. to clarify, some background:
the function signature for __libc_start_main was based on glibc, as
part of the original goal of being able to run some glibc-linked
binaries. it worked by having the crt1 code, which is linked into
every application, static or dynamic, obtain and pass pointers to the
init and fini functions, which __libc_start_main is then responsible
for using and recording for later use, as necessary. however, in
neither the static-linked nor dynamic-linked case do we actually need
crt1.o's help. with dynamic linking, all the pointers are available in
the _DYNAMIC block. with static linking, it's safe to simply access
the _init/_fini and __init_array_start, etc. symbols directly.
obviously changing the __libc_start_main function signature in an
incompatible way would break both old musl-linked programs and
glibc-linked programs, so let's not do that. instead, the function can
just ignore the information it doesn't need. new archs need not even
provide the useless args in their versions of crt1.o. existing archs
should continue to provide it as long as there is an interest in
having newly-linked applications be able to run on old versions of
musl; at some point in the future, this support can be removed.
13 years ago
|
|
|
int __libc_start_main(int (*main)(int,char **,char **), int argc, char **argv)
|
|
|
|
|
{
|
|
|
|
|
char **envp = argv+argc+1;
|
|
|
|
|
|
|
|
|
|
__init_libc(envp, argv[0]);
|
|
|
|
|
__libc_start_init();
|
|
|
|
|
|
|
|
|
|
/* Pass control to the application */
|
|
|
|
|
exit(main(argc, argv, envp));
|
|
|
|
|
return 0;
|
|
|
|
|
}
|