This is the mail archive of the binutils@sources.redhat.com mailing list for the binutils project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Linking arm thumb code


[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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]