Re: ARM Simulator Bug?

[Richard Earnshaw <rearnsha@arm.com>]

Ok, the executive summary on this is that gdb seems to have done the right 
thing (inserted a Thumb breakpoint at the appropriate point), but the 
simulator is ignoring this by treating it as a nop.  That's not very 
helpful, especially since it's then "nop"ped out a real instruction.

The reason that the behaviour changes when you drop in your link script is 
that it causes a SWI vector to be installed (at least, it does according 
to the primitive logic in the simulator), and hence SWI_vector_installed 
becomes true.

What happens is that the Thumb decoder translates the instruction into an 
ARM BKPT instruction, and it then runs the following ARM code to handle 
that:

	      if (state->is_v5)
		{
		  if (BITS (4, 7) == 0x7)
		    {
		      ARMword value;
		      extern int SWI_vector_installed;

		      /* Hardware is allowed to optionally override this
			 instruction and treat it as a breakpoint.  Since
			 this is a simulator not hardware, we take the position
			 that if a SWI vector was not installed, then an Abort
			 vector was probably not installed either, and so
			 normally this instruction would be ignored, even if an
			 Abort is generated.  This is a bad thing, since GDB
			 uses this instruction for its breakpoints (at least in
			 Thumb mode it does).  So intercept the instruction here
			 and generate a breakpoint SWI instead.  */
		      if (! SWI_vector_installed)
			ARMul_OSHandleSWI (state, SWI_Breakpoint);
		      else
			{
			  /* BKPT - normally this will cause an abort, but on the
			     XScale we must check the DCSR.  */
			  XScale_set_fsr_far (state, ARMul_CP15_R5_MMU_EXCPT, pc);
	                  if (!XScale_debug_moe (state, ARMul_CP14_R10_MOE_BT))
			    break;
			}

		      /* Force the next instruction to be refetched.  */
		      state->NextInstr = RESUME;
		      break;


Now, since SWI_vector_installed is true, we don't call ARMul_OSHandleSWI 
for this case, so the debugger never gets re-entered (normally done 
through SWI_Breakpoint).

I think the code should call ARMul_UndefInstr() if there isn't a specific 
handler for it.  The argument that if there isn't a SWI handler then there 
won't be an abort handler seems specious -- it's not an abort anyway.

This is all a mess.  But I'm not sure right now how best to start 
untangling it.

R.