Home Original page

Linking arm thumb code

Adrian von Bidder avbidder@acter.ch
Mon Nov 12 05:53:00 GMT 2001 
[deleting uclinux mailing list cc]

Nick Clifton wrote:
> > Adrian write:
> >
> > ld: Warning: type of symbol `__uClibc_main' changed from 2 to 13 in
> > __uClibc_main.o

I'm still clueless here.

> >        .weak   __init_stdio
> >        .thumb_set __init_stdio,__uClibc_empty_func
> >       ...
> >        .section        .rodata
> >        .align  2
> > .LC0:
> >        .word   __init_stdio

> Hmm, you have a PIC scheme here yes ?  So the loader is responsible
> for handling relocs that contain run time addresses ?  In which this
> may well be the problem.  For a relocation like this:

Yes. We're generating pic code, linking the final elf with -shared
-symbolic and then cripple it with elf2flt. But flat binary has a
primitive relocation mechanism.

> 
> > RELOCATION RECORDS FOR [.rodata]:
> > OFFSET   TYPE              VALUE
> > 00000000 R_ARM_ABS32       __init_stdio
> 
> If the symbol being relocated (__init_stdio) is a thumb function
> symbol (type 13) then the bottom bit must be set when the relocation
> is computed.  Have a look at the code that starts like this:

Agreed.


> in coff_arm_relocate_section in bfd/coff-arm.c for an example of
> this.

If I'm guessing right I'll have to adapt elf32_arm_final_link_relocate
in elf32-arm.h (why is this a .h????? Oh, well) to do something similar
with the case R_ARM_ABS32 where the relocation is output to the final
exec.

Now if I only knew the tiniest bit of how bfd works... Ok, ok. I'll look
into it.
 
greets from Zürich
-- vbi
More information about the Binutils mailing list