This is the mail archive of the
libc-alpha@sources.redhat.com
mailing list for the glibc project.
Problems with the ELF init_array tests
- From: Daniel Jacobowitz <drow at false dot org>
- To: libc-alpha at sources dot redhat dot com
- Cc: Paul Brook <paul at codesourcery dot com>,Mark Mitchell <mark at codesourcery dot com>
- Date: Sat, 19 Mar 2005 14:25:50 -0500
- Subject: Problems with the ELF init_array tests
The expected output for tst-array1 is:
preinit array 0
preinit array 1
preinit array 2
init
init array 0
init array 1
init array 2
fini array 2
fini array 1
fini array 0
fini
The way this normally works is that .preinit_array is run first; then
DT_INIT, then .init_array, then .fini_array. GCC puts a call to
__do_global_ctors_aux in _init, which calls the __attribute__((constructor))
functions.
I'm working on an ARM EABI port. It's configured to not use the .ctors
section at all; __attribute__((constructor)) entries are placed in
.init_array. This is mandated by the ABI. This means that init()
is placed into .init_array; exactly where in .init_array depends on
optimization and -funit-at-a-time settings. So we get this output instead:
preinit array 0
preinit array 1
preinit array 2
init array 0
init array 1
init array 2
init
fini
fini array 2
fini array 1
fini array 0
As far as I can tell, this is a conforming implementation of
__attribute__((constructor)); even a desirable one. Any suggestions on how
to adapt the tests for this implementation?
--
Daniel Jacobowitz
CodeSourcery, LLC