0

I'm practicing reversing a stripped arm binary (that I wrote) and found that when I set a breakpoint at say 0x010451, and run the program, gdb spins forever until I hit ctrl+c. When I do, the current pc is at the address, but I can't continue the program.

When I set the breakpoint to 0x010450, gdb hits the breakpoint fine, but the instructions are being decoded as non-thumb instructions.

Is this expected? A bug? I will try to upload examples later today.

Version info (under qemu usermode emulation):

debian@debian-arm:~/lab$ gdb --version
GNU gdb (Debian 8.2.1-2+b3) 8.2.1
Copyright (C) 2018 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.
debian@debian-arm:~/lab$ uname -a
Linux debian-arm 4.19.0-10-armmp-lpae #1 SMP Debian 4.19.132-1 (2020-07-24) armv7l GNU/Linux
Caustic
  • 475
  • 3
  • 14
  • Strangely, setting `set arm fallback-mode thumb` worked when `set arm fallback-mode auto` didn't. It now stops on the proper thumb instruction when setting the breakpoint to the odd address instead of spinning until I hit ctrl+c – Caustic Sep 03 '20 at 16:15
  • note the address of the label is the even number, the odd bit is consumed by the instruction (bx lr, pop {pc}, etc) and the pc only contains the even address...what gdb is expecting, dont know. – old_timer Sep 03 '20 at 17:42
  • Hmm, good point. I can't reproduce breaking on the odd numbered address like I mentioned before. `set arm fallback-mode thumb` works well enough for me now though. I'm not sure why the T bit is not being set in the register when I have fallback-mode set to auto though... – Caustic Sep 05 '20 at 15:51

0 Answers0