[Converted from Gnats 2205] I am using GDB as part of Insight, compiled as a cross-debugger for ARM targets. The programs I want to debug are written directly in assembly language and the executable is generated by GNU AS and LD (arm-elf target). When debugging, the 'nexti' command works fine until I get to a subprogram call (ARM instruction BL). Instead of stepping over the subprogram call, GDB seems to do 'continue'. At that point GDB hangs and does not respond to Ctrl-C. It seems that the bug depends on the contents of the called subprogram: inserting dummy instructions at the beginning of the subprogram maked 'nexti' work again. This bug does not occur when debugging C programs using the 'nexti' command. This bug has been observed when using GDB with the following targets : - built-in simulator (target sim) for ARM - remote/tcp (the target is an ARM7TDMI board connected to the host PC via a BDI2000 JTAG probe). Release: 6.5.0 Environment: Host: PC running Debian Etch ; Target: arm-elf How-To-Repeat: The attached file contains everything needed to rebuild the test program using GNU AS and LD for target ARM-ELF. Alternatively, the executable ELF file (appli.elf) is provided. Run arm-elf-gdb for target 'sim'. Load file appli.elf and step over each instruction using command 'nexti'. The bug occurs when reaching line 37 ("bl sum") in source file "main.s". Command 'nexti' makes GDB hang. Edit file 'sum.s' uncomment line 22 and rebuild appli.elf. This will insert a NOP instruction at the beginning of the subprogram. After doing this, command 'nexti' works correctly.
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.