add support for init/fini array in main program, and greatly simplify
authorRich Felker <dalias@aerifal.cx>
Sun, 21 Jul 2013 07:00:54 +0000 (03:00 -0400)
committerRich Felker <dalias@aerifal.cx>
Sun, 21 Jul 2013 07:00:54 +0000 (03:00 -0400)
commit7586360badcae6e73f04eb1b8189ce630281c4b2
treeb8b3e2c0d10a0dea082750d03c9ce462b6ee07f3
parent1b413572b271ebb93af38d73fa57eb85175e8a50
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.
src/env/__libc_start_main.c
src/exit/exit.c
src/internal/libc.h
src/ldso/dynlink.c