[patch] init_array/fini_array support

Joakim Tjernlund 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
> 
> And:
> 
> 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:
> 
> http://bugs.busybox.net/view.php?id=385
> 
> 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
weak syms:
extern weak fun();
if (fun)
    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?

 Jocke




More information about the uClibc mailing list