This is the mail archive of the
binutils@sources.redhat.com
mailing list for the binutils project.
Re: Linking arm thumb code
- From: Adrian von Bidder <avbidder at acter dot ch>
- To: Phil Blundell <pb at nexus dot co dot uk>
- Cc: binutils <binutils at sources dot redhat dot com>
- Date: Thu, 22 Nov 2001 15:13:40 +0100
- Subject: Re: Linking arm thumb code
- References: <3BFCF28D.75556C34@acter.ch> <E166u5U-0001YE-00@mill.nexus.co.uk>
[I'm deleting the cc to the uclinux list]
Phil Blundell wrote:
>
> >ld: Warning: type of symbol `__uClibc_main' changed from 2 to 13 in
> >__uClibc_main.o
>
> Type 2 is plain old STT_FUNC; type 13 is STT_TFUNC. I'm not sure why this
> warning is turning up, but I don't think it's directly related to the problem
> you're having.
Ok.
>
> > .weak __init_stdio
> > .thumb_set __init_stdio,__uClibc_empty_func
> > ...
> > .section .rodata
> > .align 2
> >.LC0:
> > .word __init_stdio
>
> I think ".thumb_set" is supposed to mark the symbol as being of Thumb type.
> That should mean that the low bit gets set, causing BX to do the right thing.
>
> Can you check the final linked executable and make sure this isn't happening?
Hmm, let's see. gdb session is:
===
Breakpoint 1, 0x9014d4ac in __uClibc_main ()
1: x/i $pc 0x9014d4ac <__uClibc_main+20>:
bl 0x9014d544 <_call_via_r0>
(gdb) stepi
0x9014d544 in _call_via_r0 ()
1: x/i $pc 0x9014d544 <_call_via_r0>: bx r0
(gdb) print/x $r0
$1 = 0x9014d4d0
(gdb) disass $r0
Dump of assembler code for function __uClibc_empty_func:
0x9014d4d0 <__uClibc_empty_func>: bx lr
0x9014d4d2 <__uClibc_empty_func+2>: nop (mov r8,r8)
End of assembler dump.
#So r0 points to the right function. Manually setting the lsb of r0 lets
me #continue past this point:
(gdb) set $r0=$r0+1
(gdb) stepi
0x9014d4d0 in __uClibc_empty_func ()
1: x/i $pc 0x9014d4d0 <__uClibc_empty_func>: bx lr
(gdb) print/x $lr
$2 = 0x9014d4b1
===
So bx here will correctly jump back. Without manual adjustment of r0 it
crashes really weird:
===
Breakpoint 1, 0x9014d4ac in __uClibc_main ()
1: x/i $pc 0x9014d4ac <__uClibc_main+20>:
bl 0x9014d544 <_call_via_r0>
(gdb) stepi
0x9014d544 in _call_via_r0 ()
1: x/i $pc 0x9014d544 <_call_via_r0>: bx r0
(gdb) print/x $r0
$1 = 0x9014d4d0
# and now I don't know what happens, but I suspect it's just gdb not
seeing
# that the simulator really is executing in ARM, not thumb. pc increment
is
# 4, so we're really in ARM state here.
(gdb) stepi
0x9014d4d0 in __uClibc_empty_func ()
1: x/i $pc 0x9014d4d0 <__uClibc_empty_func>: bx lr
(gdb)
0x9014d4d4 in exit ()
1: x/i $pc 0x9014d4d4 <exit>: push {r4, lr}
(gdb)
No mem: ARMul_readWord: @ 7261656a (kernel mode)
===
But of course this could also be the loader or elf2flt. Hmmm. I'm not
familiar enough with objdump and elf, so you'd have to assist me here.
greets from Zürich
-- vbi