failed to single step over bad thumb->arm boundary

[Dr. David Alan Gilbert]

Hardware: Beagleboard
gdb built from gdb-linaro/7.2 bzr rev 32978

I screwed upa thumb assembler file by missing the .thumb_func off, while trying to figure this out I tried single stepping with gdb, however the gdb doesn't stop at the incorrect branch (which I think is trying to branch to my thumb code as ARM code):

----------------------------------------------
$ more wrapper.c
#include <stdio.h>

extern int foo(int a,int b);

int main()
{
  printf("Result: %d\n", foo(5,6));
}

----------------------------------------------
$ more simple.s
 .thumb
 .text
 .align 2
 .global foo
 .thumb

foo:
  mov r0,#42
  bx lr

----------------------------------------------

cross build it:

arm-linux-gnueabi-gcc -I/usr/arm-linux-gnueabi/include -c -o wrapper.o wrapper.c
arm-linux-gnueabi-as -o simple.o simple.s
arm-linux-gnueabi-gcc -I/usr/arm-linux-gnueabi/include -o fiddle wrapper.o simple.o -lc

scp fiddle across to beagle and:

# ./try/bin/gdb ./fiddle
GNU gdb (Linaro GDB) 7.2-2010.10-1-bzr
Copyright (C) 2010 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law. Type "show copying"
and "show warranty" for details.
This GDB was configured as "armv7l-unknown-linux-gnueabi".
For bug reporting instructions, please see:
<http://bugs.launchpad.net/gdb-linaro/>...
Reading symbols from /root/fiddle...(no debugging symbols found)...done.
(gdb) break main
Breakpoint 1 at 0x83b0
(gdb) set lang asm
(gdb) display/i $pc
(gdb) r
Starting program: /root/fiddle

Breakpoint 1, 0x000083b0 in main ()
1: x/i $pc
=> 0x83b0 <main+8>: movt r4, #0
(gdb) si
0x000083b4 in main ()
1: x/i $pc
=> 0x83b4 <main+12>: mov.w r0, #5
(gdb)
0x000083b8 in main ()
1: x/i $pc
=> 0x83b8 <main+16>: mov.w r1, #6
(gdb)
0x000083bc in main ()
1: x/i $pc
=> 0x83bc <main+20>: blx 0x83d0 <foo>
(gdb) disassemble 0x83d0
Dump of assembler code for function foo:
   0x000083d0 <+0>: movs r0, #42 ; 0x2a
   0x000083d2 <+2>: bx lr
End of assembler dump.
(gdb) si
Result: 66656

Program exited normally.
(gdb)

[Yao Qi (yao-codesourcery)]

First of all, .thumb_func is missing in simple.s, I got SIGILL when I run fiddle on my system.

lp667309$ ./fiddle
Illegal instruction

When I add .thumb_func in simple.s, everything works well in both Linaro GDB and FSF GDB head.

I don't think simple.s is a proper case, since itself is not correct. I am inclined to turn this ticket as INVALID.

[Dr. David Alan Gilbert (davidgil-uk)]

Yes as mentioned in the bug I realise that .thumb_func is missing - but I didn't at first and that's why
I ended up in gdb trying to work out why it failed!

The fact your copy SIGILL's is reasonable - I think it just depends what was after the end of the routine, mine
happens to find a return and carry on just providing a wrong value.

I'd be OK with you closing it as invalid I guess - but I also suspect it's not too uncommon for people to mess up ARM/Thumb transitions, and hence if gdb can tell it's about to switch into ARM then it should plant the appropriate breakpoint to stop in ARM.

Dave

[Yao Qi (yao-codesourcery)]

You overestimate GDB, :-) I agree with your statement. Maybe linker can emit a warning when it meets such case.

[Ulrich Weigand (uweigand)]

I've looked into this issue again, and I tend to agree with Yao's assessment. There is not a lot GDB can do: when it sets a breakpoint at a code address, it doesn't necessarily know how / from where this will be called, so it has to rely on static code properties to determine whether it's ARM or Thumb. And even if it could determine in particular cases that a call in ARM mode to a Thumb target is being attempted, there's still no way to safely set an ARM breakpoint in Thumb code (since the ARM breakpoint may be longer than a Thumb instruction).

As suggested by Yao and agreed to by David, I'm setting this to Invalid now.

[Peter Maydell (pmaydell)]

I'm inclined to disagree that this is invalid (although it certainly isn't very far up our priority list). Single-step-instruction in a single-threaded program should never just go off into the weeds: gdb is always in a position to either put a breakpoint of the right type at the next location, or complain that it's unable to do so.

[Ulrich Weigand (uweigand)]

OK; I'll see if I can come up with a fix.

[Ulrich Weigand (uweigand)]

Patch posted here:
http://sourceware.org/ml/gdb-patches/2011-03/msg01077.html

[Ulrich Weigand (uweigand)]

Fix committed upstream and to Linaro GDB 7.2