[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