gdb won't single-step over ARM integer divide opcode

John Breitenbach
Wed Aug 5 18:03:00 GMT 2015

I'm trying to debug a program compiled for a cortex-a53 using gcc-4.9.3 
with gdb-7.9.1, and when I attempt to single-step through an sdiv 
opcode, gdb won't step.  And it gives me a message about being unable to 
access memory:

1: x/i $pc
=> 0x8310 <main+32>:    sdiv    r2, r2, r4
Cannot access memory at address 0xffffd8f0

I did some debugging and have found that the function, 
arm_get_next_pc_raw, inappropriately decodes this opcode as a load into 
the PC register.  (bits 24..27 are 7, bit 20 is set, and the dest 
register appears to be the PC.

Binutils's logic to disassemble the sdiv/udiv opcodes has opcode & 
0x0ff0f0f0 = 0x0710f010 (with bit 21 distinguishing between udiv and sdiv)

I've come up with the following patch which makes my situation work. But 
I don't know how complete it is, as there may be other newer opcodes 
which fall into the formerly undefined instruction space.

Also, the comment "byte write to PC" around line 4930 seems wrong, as 
the check for bit 22 a few lines earlier catches that situation, and 
what's left is word writes to the PC."


  gdb/arm-tdep.c | 9 ++++++++-
  1 file changed, 8 insertions(+), 1 deletion(-)

diff --git a/gdb/arm-tdep.c b/gdb/arm-tdep.c
index 8e9552a..79da43e 100644
--- a/gdb/arm-tdep.c
+++ b/gdb/arm-tdep.c
@@ -4912,10 +4912,17 @@ arm_get_next_pc_raw (struct frame_info *frame, 

+    case 0x7:
+        /* sdiv/udiv using masks from binutils/opcodes/arm-dis.c,
+          * otherwise, we think sdiv/udiv is a write to pc reg
+          */
+        if( (this_instr & 0x0fd0f0f0) == 0x0710f010)
+            break;
+        /* intentional fall-though to case 4..6 */
      case 0x4:
      case 0x5:        /* data transfer */
      case 0x6:
-    case 0x7:
        if (bit (this_instr, 20))
            /* load */

More information about the Gdb mailing list