[patch] init_array/fini_array support

Peter S. Mazinger ps.m at gmx.net
Mon Jan 30 09:25:15 UTC 2006


On Sun, 29 Jan 2006, Joseph S. Myers wrote:

> On Tue, 24 Jan 2006, Joakim Tjernlund wrote:
> 
> > > What do you think of the size increase? Couldn't we move at 
> > > least some of it to ld.so? Is there some other reason to have 
> > > them local in the binary?
> > 
> > That's an interesting idea, but not so easy I think. One would have to move
> > the apps _init/_fini processing to ld.so and remove them from crt1 or some combination
> > of both to support static linking.
> 
> Indeed, static binaries need __libc_csu_fini so avoiding it altogether for 
> dynamic binaries (instead calling destructors from ld.so) would mean 
> different copies of crt1 for static and dynamic linking.

I am not thinking of providing different crt1.o files. Now we put one copy 
into nonshared.a (for dynamic binaries) and one into libc.a for static 
binaries. So the static binaries would be the same. Where we could save 
some size are the dynamic binaries only, moving it out of nonshared.a.
Would it be possible to add __libc_csu_init/fini to libc.so, or is it too 
late/early? Is there a specific reason to have it in nonshared.a 
(we don't have to mimic glibc for this) ? Does each binary have to have 
it's own copy of it?

Under current circumstances I would rather add this patch conditionally  
guarded by a config option (due to the size increase in each binary)

Thanks, Peter

-- 
Peter S. Mazinger <ps dot m at gmx dot net>           ID: 0xA5F059F2
Key fingerprint = 92A4 31E1 56BC 3D5A 2D08  BB6E C389 975E A5F0 59F2




More information about the uClibc mailing list