Summary: | nexti command does not work when debugging ARM assembly language | ||
---|---|---|---|
Product: | gdb | Reporter: | guillaume.savaton |
Component: | gdb | Assignee: | Not yet assigned to anyone <unassigned> |
Status: | RESOLVED FIXED | ||
Severity: | critical | CC: | gdb-prs, pedro, will.newton, zhudonghai |
Priority: | P1 | ||
Version: | 7.5 | ||
Target Milestone: | 7.5 | ||
Host: | x86_64-unknown-linux-gnu | Target: | arm-linux-androideabi |
Build: | x86_64-unknown-linux-gnu | Last reconfirmed: | |
Attachments: | arm-elf-gdb-bug-nexti.tar.gz |
Description
guillaume.savaton
2006-11-23 08:28:01 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. 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. 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. > "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?
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. |