[patch] init_array/fini_array support
joakim.tjernlund at transmode.se
Tue Jan 31 23:57:47 UTC 2006
> -----Original Message-----
> From: uclibc-bounces at uclibc.org
> [mailto:uclibc-bounces at uclibc.org] On Behalf Of John Bowler
> Sent: den 31 januari 2006 19:15
> To: 'Joseph S. Myers'; 'Peter S. Mazinger'
> Cc: uclibc at uclibc.org
> Subject: RE: [patch] init_array/fini_array support
> RE: PATCH: Make environ a weak alias to __environ
> I don't understand what is going on here. In 0.9.28 it
> doesn't work at all on ARM uclibc to have a weak alias in a DLL, i.e.
> it doesn't work at all to define a visible DLL symbol weak.
> It works fine on ARM glibc.
> See the comment in ldso/dl-hash.c "Perhaps we should support
> old style weak symbol handling per what glibc does when you
> export LD_DYNAMIC_WEAK." - the code to handle weak symbols is
> commented out.
> What this means is that, on uclibc alone, ld.so simply
> ignores weak symbol definitions in a DLL - so if you don't
> have a strong one the symbol will be undefined.
> I encountered this on thumb because the 'undefined' symbol
> for a thumb function appeared, in this context, to be a
> definition (because of the setting of the low bit) and ld.so
> ended up calling an SHN_UNDEF
> (value==1) function in preference to the weak definition (in
> the case when the strong one is absent.)
> This is the reason for the core parts of
> 20060120-thumb-resolve.patch in:
> Anyway, I don't understand why *not* having weak symbol
> handling in ld.so is correct, but Joakim Tjernlund made this comment:
> From: Joakim Tjernlund [mailto:joakim.tjernlund at transmode.se]
> Sent: Sunday, January 22, 2006 4:22 AM
> To: jbowler at acm.org; uclibc at uclibc.org
> Subject: RE: uClibc ARM thumb support
> > The dl_hash.c changes does not look sane to me, looks like you have
> > restored the old WEAK procedure(among some other stuff that I don't
> > understand yet)? Why?
> So I'm missing something here - in 0.9.28 there was no *new*
> WEAK procedure (in so far as weak symbols were not being
> resolved), maybe there is a new one and it is broken?
Weak symbols are handled in ld.so, but how they are handled changed(between .26 and .27 I think)
Look in elfinterp.c for:
if (unlikely(!symbol_addr && ELF32_ST_BIND(symtab[symtab_index].st_info) != STB_WEAK))
The ld.so was a mess when I started to fix it up(around .26) and at that time I found that
glibc had changed how the handled weak syms so I did the same to uclibc.
earlier ld.so would try to find a strong sym before resorting to a weak sym, now ld.so will
use the first sym it finds, does not matter if its weak or strong. This
will break a few apps/libs(linuxthreads was one). Now you will have to use something like this for
extern weak fun();
from what you have told me I think the only difference for thumb is that thumb transforms
the STT_ATM_TFUNC into value=1 instead. You will have to do something in dl_find_hash
to resolve this correctly.
did you try my suggestion and did it make it better?
More information about the uClibc