Mirror of the gdb mailing list
 help / color / mirror / Atom feed
* gdb won't single-step over ARM integer divide opcode
@ 2015-08-05 18:03 John Breitenbach
  2015-08-09 11:39 ` Yao Qi
  0 siblings, 1 reply; 3+ messages in thread
From: John Breitenbach @ 2015-08-05 18:03 UTC (permalink / raw)
  To: gdb

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."

John

---
  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, 
CORE_ADDR pc)
          break;
        }

+    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 */
-- 
1.9.3


^ permalink raw reply	[flat|nested] 3+ messages in thread

* Re: gdb won't single-step over ARM integer divide opcode
  2015-08-05 18:03 gdb won't single-step over ARM integer divide opcode John Breitenbach
@ 2015-08-09 11:39 ` Yao Qi
  2015-08-10 14:58   ` John Breitenbach
  0 siblings, 1 reply; 3+ messages in thread
From: Yao Qi @ 2015-08-09 11:39 UTC (permalink / raw)
  To: John Breitenbach, gdb

On 05/08/15 19:02, John Breitenbach wrote:
> 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.

Hi John,
Thanks for your patch, however, I think I've fixed this problem in
patch https://sourceware.org/ml/gdb-patches/2015-06/msg00610.html
Does it work for you?  This commit will be in 7.10 release.

>
> 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."
>

Yeah, it is possible.  Patch is welcome :)

-- 
Yao (齐尧)


^ permalink raw reply	[flat|nested] 3+ messages in thread

* Re: gdb won't single-step over ARM integer divide opcode
  2015-08-09 11:39 ` Yao Qi
@ 2015-08-10 14:58   ` John Breitenbach
  0 siblings, 0 replies; 3+ messages in thread
From: John Breitenbach @ 2015-08-10 14:58 UTC (permalink / raw)
  To: gdb

Yao,
   Yes, your patch does work for me.  Sorry for not noticing your patch
earlier.

John

On 08/09/2015 07:39 AM, Yao Qi wrote:
> On 05/08/15 19:02, John Breitenbach wrote:
>> 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.
>
> Hi John,
> Thanks for your patch, however, I think I've fixed this problem in
> patch https://sourceware.org/ml/gdb-patches/2015-06/msg00610.html
> Does it work for you?  This commit will be in 7.10 release.
>
>>
>> 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."
>>
>
> Yeah, it is possible.  Patch is welcome :)
>


^ permalink raw reply	[flat|nested] 3+ messages in thread

end of thread, other threads:[~2015-08-10 14:58 UTC | newest]

Thread overview: 3+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2015-08-05 18:03 gdb won't single-step over ARM integer divide opcode John Breitenbach
2015-08-09 11:39 ` Yao Qi
2015-08-10 14:58   ` John Breitenbach

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox