uClibc ARM thumb support

John Bowler jbowler at acm.org
Sun Jan 22 18:58:32 UTC 2006


From: Joakim Tjernlund [mailto:joakim.tjernlund at transmode.se]
>Did a little research since our last chat. Found this:
>  . If the st_shndx member of the symbol table entry is not SHN_UNDEF, the dynamic linker
>  has found a definition for the symbol and uses its st_value member as the symbol's
>  address.
>  . If the st_shndx member is SHN_UNDEF and the symbol is of type STT_FUNC and the
>  st_value member is not zero, the dynamic linker recognizes this entry as special and uses
>  the st_value member as the symbol's address.

Yes, well, with binutils-2.16 we get st_value==1 IIRC and there are
no cases I could find where the st_value != {0,1}

I suspect the sequence of actions is that gcc (3.4.4) is run -mthumb and
generates function references as SHN_UNDEF/STT_ARM_TFUNC(0) then binutils
fixes these up to SHN_UNDEF/STT_FUNC(1), which creates the problem.

>This shows that there are cases when SHN_UNDEF is a valid target.

Well, no, it shows that the ELF specific allows this, but that doesn't mean it
ever happens.  Of course it may well happen in non-ARM systems or with non-gcc
code.  As you say, the specific test:

STT_FUNC && SHN_UNDEF && st_value == 1 && (arm && interwork || thumb)

is safer.

>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? 

Because I observed that some of the DLL init/fini handling declares weak
symbols (I think) and I added weak definitions of the _call_via_rX stuff.
That was because _call_via_ip is simply impossible via a DLL and, for
everything else, using a PLT to execute *one* instruction in a DLL is,
IMO, really dumb particularly as it happens on any indirect function call.

Anyway, I believe the *other* patches should be applied to uClibc and
this one left out.  OpenEmbedded will still keep working (because it
will apply it) and anyone who uses the thumb stuff outside OE has to
patch binutils and libgcc anyway.  Debugging any crashes shouldn't take
more than a couple of weeks particularly if this patch is still around to
give hints.

At present it's simply impossible to know if the system works without
the patch because the SVN head itself didn't work on the complex examples
which failed before in these cases.

Not all DLLs fail - only those with fairly sophisticated init/fini stuff.
IIRC glib-2.0 is an example and something which linked with ncurses would
show problems.

If things move to EABI this stuff will all become moot anyway - the set of
bugs with gcc-4.x and EABI binutils will surely be very different.

John Bowler <jbowler at acm.org>




More information about the uClibc mailing list