This is the mail archive of the
binutils@sources.redhat.com
mailing list for the binutils project.
Re: Linking arm thumb code
[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