gdb 5.3 problem in ARM simulator

[Hornung Peter <peter_hornung at siemens dot com>]

Hi,

this patch fixes a problem in the ARM simulator when executing a mode
change. Please see attached emails for explanation.
The bug fix skips increasing state->Reg[15] by 2 instructions during a mode
change.

This is the patch:
--- gdb-5.3.orig/sim/arm/armemu.c	2002-07-05 16:12:01.000000000 +0200
+++ gdb-5.3/sim/arm/armemu.c	2003-04-25 16:17:19.000000000 +0200
@@ -3556,7 +3556,15 @@ check_PMUintr:
 	state->Emulate = STOP;
       /* If we have changed mode, allow the PC to advance before stopping.
*/
       else if (state->Emulate == CHANGEMODE)
-	continue;
+	{
+	  pc = state->Reg[15];
+#ifndef MODE32
+	  pc = pc & R15PCBITS;
+#endif
+	  state->Reg[15] = pc;
+	  state->NextInstr = RESUME;
+	  break;
+	}
       else if (state->Emulate != RUN)
 	break;
     }


Regards,
Peter Hornung

----------------------------------------------------------------------------
-------------

Peter Hornung, Siemens A&D PT1 D1,
Siemensstraße 2, 90766 Fürth, Germany
E-Mail: Peter_Hornung at siemens dot com
Tel: +49-911-978-2013, Fax: +49-911-978-2035

--- Begin Message ---

• From: Hornung Peter <peter_hornung at siemens dot com>
• To: "'nickc at redhat dot com'" <nickc at redhat dot com>
• Date: Fri, 25 Apr 2003 10:57:41 +0200
• Subject: gdb 5.3 problem in ARM simulator
• Return-receipt-to: Hornung Peter <peter_hornung@siemens.com>

Hi Nick,

I discovered a problem in gdb 5.3 while running ARM7 code (uClinux) in the
simulator. The code worked in the gdb 5.0 simulator but crashed in the 5.3
one. I attached a small trace of the executed code. The trace was done with
gdb 5.0:
pc: 100a9c8, instr: e95d7ffe
pc: 100a9cc, instr: e1a00000
pc: 100a9d0, instr: e28dd00c
pc: 100a9d4, instr: e1b0f00e	(1)
pc: 1411f10, instr: e3a0b000	(2)
pc: 1411f14, instr: e59d0000	(3)
pc: 1411f18, instr: e59d1004
pc: 1411f1c, instr: e59d2008
pc: 1411f20, instr: eb000b16
pc: 1414b80, instr: e24dd004
pc: 1414b84, instr: e3a03000
pc: 1414b88, instr: e58d3000

When I run the code in gdb 5.3, line (2) still is being traced, but not
executed. Line (3) is not even traced. Until Line (1) everything is executed
in the function ARMul_Emulate32. After this line a mode change is done and
the following lines are executed in the function ARMul_Emulate26.

You did a change a few years ago at the end of the ARMul_EmulateXX functions
to stay in the function to adjust the pc in case of a mode change:
	      if (state->Emulate == ONCE)
		state->Emulate = STOP;
	      /* If we have changed mode, allow the PC to advance before
stopping.  */
(A)	      else if (state->Emulate == CHANGEMODE)
(B)		continue;
	      else if (state->Emulate != RUN)
		break;
	    }
	  while (!stop_simulator);
	
	  state->decoded = decoded;
	  state->loaded = loaded;
	  state->pc = pc;
	
	  return pc;
	}

In case of a mode change state->Reg[15] is adjusted at the start of the
ARMul_Emulate32 fuction by 2 instructions and ARMul_Emulate26 starts then 2
instructions too late with the execution.

When I remove the lines (A) and (B), the simulator works for me, but I have
no idea about the side effects of this.

What is your opinion about this?


Regards,
Peter Hornung

----------------------------------------------------------------------------
-------------

Peter Hornung, Siemens A&D PT1 D1,
Siemensstraße 2, 90766 Fürth, Germany
E-Mail: Peter_Hornung at siemens dot com
Tel: +49-911-978-2013, Fax: +49-911-978-2035

--- End Message ---

--- Begin Message ---

• From: Nick Clifton <nickc at redhat dot com>
• To: Hornung Peter <peter_hornung at siemens dot com>
• Date: Fri, 25 Apr 2003 12:04:51 +0200
• Subject: Re: gdb 5.3 problem in ARM simulator

Hi Peter,

> You did a change a few years ago at the end of the ARMul_EmulateXX
> functions to stay in the function to adjust the pc in case of a mode
> change: 
> 	      if (state->Emulate == ONCE)
> 		state->Emulate = STOP;
> 	      /* If we have changed mode, allow the PC to advance before
> stopping.  */
> (A)	      else if (state->Emulate == CHANGEMODE)
> (B)		continue;
> 	      else if (state->Emulate != RUN)
> 		break;
> 	    }
> 	  while (!stop_simulator);

> In case of a mode change state->Reg[15] is adjusted at the start of
> the ARMul_Emulate32 fuction by 2 instructions and ARMul_Emulate26
> starts then 2 instructions too late with the execution.
> 
> When I remove the lines (A) and (B), the simulator works for me, but
> I have no idea about the side effects of this.
> 
> What is your opinion about this?

Hmm, to be honest I do not remember exactly why I put in this change,
but I am pretty sure it was because Intel were complaining about not
being able to single step through mode changes.  I also think that at
the time I was rather dubious of my patch, but it kept them happy, so
I let it in.

Since the patch obviously breaks tracing through mode changes I think
that it ought to be reverted.  Could you try removing it and then
seeing if you can single step through the change, as well as just
running normally ?  If both of these work, please submit (a
pre-approved) patch to the gdb mailing list to revert the change.

Cheers
        Nick

--- End Message ---

Attachment: ChangeLog
Description: Binary data