From 783e641fbae0cd1ab32d278216247a6f793dd722 Mon Sep 17 00:00:00 2001 From: Florian Weimer Date: Mon, 24 Feb 2020 11:50:24 +0100 Subject: csu: Use ELF constructor instead of _init in libc.so On !ELF_INITFINI architectures, _init is no longer called by the dynamic linker. We can use an ELF constructor instead because the constructor order does not matter. (The other constructors are used to set up libio vtable bypasses and do not depend on this initialization routine.) --- csu/init-first.c | 12 ++++++------ 1 file changed, 6 insertions(+), 6 deletions(-) (limited to 'csu') diff --git a/csu/init-first.c b/csu/init-first.c index 1cd8a75098..264e6f348d 100644 --- a/csu/init-first.c +++ b/csu/init-first.c @@ -43,12 +43,11 @@ void __libc_init_first (int argc, char **argv, char **envp) { #ifdef SHARED - /* For DSOs we do not need __libc_init_first but instead _init. */ + /* For DSOs we do not need __libc_init_first but an ELF constructor. */ } -void -attribute_hidden -_init (int argc, char **argv, char **envp) +static void __attribute__ ((constructor)) +_init_first (int argc, char **argv, char **envp) { #endif @@ -86,8 +85,9 @@ _init (int argc, char **argv, char **envp) /* This function is defined here so that if this file ever gets into ld.so we will get a link error. Having this file silently included - in ld.so causes disaster, because the _init definition above will - cause ld.so to gain an init function, which is not a cool thing. */ + in ld.so causes disaster, because the _init_first definition above + will cause ld.so to gain an ELF constructor, which is not a cool + thing. */ extern void _dl_start (void) __attribute__ ((noreturn)); -- cgit 1.4.1