[uClibc]all your constructors are belong to us
Phil Hopely
phil at ayrnetworks.com
Tue Jul 30 00:35:09 UTC 2002
Hi folks,
I wish to confirm an empirical observation:
I have some code that I am trying to make go with uclibc, but which has
a few functions that are assigned gcc extensions of "__attribute__
((constructor))".
My undestanding is that pointers to these get populated into an elf
section w/ a particular elf type SHT_CONSTRUCTOR or something
thereabouts. Mr. (Gnu) Loader, after he spooges all elf sections with
their ALLOC flag set, yet just prior to getting down to business in
main(), takes a stroll over this section and roll calls each member.
objdump -x shows me that there is in fact an elf section w/ the name
".ctors" present in the uclibc-generated object file, as per:
...
9 .rld_map 00000004 100011e0 100011e0 001091e0 2**2
CONTENTS, ALLOC, LOAD, DATA
10 .ctors 00000074 100011e4 100011e4 001091e4 2**2
CONTENTS, ALLOC, LOAD, DATA
11 .got 00000694 10001260 10001260 00109260 2**4
CONTENTS, ALLOC, LOAD, DATA
...
So I can see that this information should be available to Mr. (uClibc)
Loader, should he so choose to get jiggy with it.
But practice seems to indicate Mr. Loader is being a wallflower and not
getting down into the constructor scene...
Do I need to do Something Special to make Mr. uClibc Loader have the
self-confidence to boogie with the best of them on the initialization
dance floor? Or does Mr. uClibc Loader need a little brain surgery, in
which case I've got my swisse army knife ready and willing.
thanks,
Phil
More information about the uClibc
mailing list