[Bug gdb/9310] nexti command does not work when debugging ARM assembly language

[Bug gdb/9310] nexti command does not work when debugging ARM assembly language

[zhudonghai at gmail dot com]

http://sourceware.org/bugzilla/show_bug.cgi?id=9310

zhudonghai at gmail dot com changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Target|                            |arm-linux-androideabi
           Priority|P3                          |P1
            Version|5.0                         |7.5
                 CC|                            |zhudonghai at gmail dot com
               Host|                            |x86_64-unknown-linux-gnu
   Target Milestone|---                         |7.5
           Severity|enhancement                 |critical
              Build|                            |x86_64-unknown-linux-gnu

--- Comment #1 from zhudonghai at gmail dot com 2012-10-26 08:40:50 UTC ---
reproduced on gdb 7.5 when remote debugging android. when nexti over blx and
bl,
it may cause sigsegv or act like an stepi command.

-- 
Configure bugmail: http://sourceware.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.

[Bug gdb/9310] nexti command does not work when debugging ARM assembly language

[palves at redhat dot com]

http://sourceware.org/bugzilla/show_bug.cgi?id=9310

Pedro Alves <palves at redhat dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |palves at redhat dot com

--- Comment #2 from Pedro Alves <palves at redhat dot com> 2012-10-26 18:38:19 UTC ---
ARM or Thumb?  A fix went in on 2012-08-22, for Thumb 'bx pc' and 'blx pc'.

Otherwise, it may be simpler if you could debug this.  Here's how.

Debug the arm gdb with the host's (x86, I presume) gdb.  On the (arm/android)
gdb, and put a breakpoint on that particular bl instruction's address, and run
to it (b *0xADDR; c).  Then, on the top (x86) gdb, set a breakpoint on
arm_get_next_pc, and let the android gdb continue.  Tell the android GDB to
continue the android program as well.  arm_get_next_pc will be hit.  This is
the function that computes where the execution will land next, so GDB can put a
breakpoint there, so that the android program executes only one instruction (is
single-stepped).  The symptom of the bug usually means that for some reason
this computing the next pc goes wrong.  It's usually evident whether the
computed address looks reasonable or not.

-- 
Configure bugmail: http://sourceware.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.

[Bug gdb/9310] nexti command does not work when debugging ARM assembly language

[zhudonghai at gmail dot com]

http://sourceware.org/bugzilla/show_bug.cgi?id=9310

--- Comment #3 from zhudonghai at gmail dot com 2012-10-27 09:10:49 UTC ---
I have done that yet, stepi always correctly single-step one instruction but
nexti can't correctly step over the call instruction like bl or blx. I always
use gdb reverse engineering some android app without symbol, and I want gdb can
act like windbg, the debugger on windows platform. I also have tested gdb 7.1
i386 version, nexti command can't always step over the call instruction
correctly. gdb is a versatile source debugger, maybe it is not very suitable
for reverse engineering.

-- 
Configure bugmail: http://sourceware.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.

[Bug gdb/9310] nexti command does not work when debugging ARM assembly language

[palves at redhat dot com]

http://sourceware.org/bugzilla/show_bug.cgi?id=9310

Pedro Alves <palves at redhat dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|ASSIGNED                    |WAITING

--- Comment #4 from Pedro Alves <palves at redhat dot com> 2012-11-22 18:50:20 UTC ---
> "some android app without symbol"

I see.  "nexti" works by internally:

 #1 - single-stepping.
 #2 - gdb's frame unwinder notices a new frame has been entered.
 #3 - gdb figures out where the function will return to (unwinds the PC),
   and sets a breakpoint at the return location.
 #4 - let's the program run until that breakpoint is hit.

I'd guess that #3 is failing for you, due to missing unwind/debug info.
Try "stepi", and then "up" once.  Does the PC point at where you'd expect 
the bl/blx would return to?

-- 
Configure bugmail: http://sourceware.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.

[Bug gdb/9310] nexti command does not work when debugging ARM assembly language

[will.newton at gmail dot com]

https://sourceware.org/bugzilla/show_bug.cgi?id=9310

Will Newton <will.newton at gmail dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|WAITING                     |RESOLVED
                 CC|                            |will.newton at gmail dot com
         Resolution|---                         |FIXED

--- Comment #5 from Will Newton <will.newton at gmail dot com> ---

The original issue in this bug report appears to be fixed:

GNU gdb (GDB) 7.6.50.20131021-cvs
Copyright (C) 2013 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 "--host=x86_64-unknown-linux-gnu
--target=arm-none-elf".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>.
Find the GDB manual and other documentation resources online at:
<http://www.gnu.org/software/gdb/documentation/>.
For help, type "help".
Type "apropos word" to search for commands related to "word"...
Reading symbols from appli.elf...done.
(gdb) target sim
Connected to the simulator.
(gdb) load
Loading section .text, size 0xac vma 0x20
Loading section .data, size 0x128 vma 0x4020
Start address 0x70
Transfer rate: 3744 bits in <1 sec.
(gdb) break start
Breakpoint 1 at 0x74: file main.s, line 33.
(gdb) run
Starting program:
/home/will/linaro/binutils-gdb/arm-elf-gdb-bug-nexti/appli.elf 

Breakpoint 1, start () at main.s:33
warning: Source file is more recent than executable.
33      ldr r0, =tab3
(gdb) nexti
34      ldr r1, =tab1
(gdb) 
35      ldr r2, =tab2
(gdb) 
36      mov r3, #TAILLE
(gdb) 
37      bl sum
(gdb) 
39      nop
(gdb) run
The program being debugged has been started already.
Start it from the beginning? (y or n) y
Starting program:
/home/will/linaro/binutils-gdb/arm-elf-gdb-bug-nexti/appli.elf 

Breakpoint 1, start () at main.s:33
33      ldr r0, =tab3
(gdb) nexti
34      ldr r1, =tab1
(gdb) 
35      ldr r2, =tab2
(gdb) 
36      mov r3, #TAILLE
(gdb) 
37      bl sum
(gdb) stepi
sum () at sum.s:19
warning: Source file is more recent than executable.
19      stmfd sp!, {r4, r5, lr}
(gdb) up
#1  0x00000088 in start () at main.s:37
37      bl sum

If there are further issues, e.g. on i386 then they should really be part of a
new bug report with it's own testcase.

-- 
You are receiving this mail because:
You are on the CC list for the bug.