uClibc ARM thumb support

Paul Brook paul at codesourcery.com
Sun Jan 22 19:16:38 UTC 2006


On Sunday 22 January 2006 18:58, John Bowler wrote:
> 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.

It depends which ABI you're using.
Old-abi toolchains indicate thumb functions by giving them type STT_ARM_TFUNC.
EABI toolchains give them type STT_FUNC and set the low bit of the address.

Note that because of the way this is implemented in BFD, the output of objdump 
may not accurately reflect the contents of the file.

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

Mainline binutils and gcc should both work fine in thumb mode.

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

Recent toolchains don't use these symbols anyway.

Paul



More information about the uClibc mailing list