This is the mail archive of the
insight@sources.redhat.com
mailing list for the Insight project.
Re: ARM Simulator Bug?
- From: Richard Earnshaw <rearnsha at arm dot com>
- To: mckennad at esatclear dot ie
- Cc: Richard Earnshaw <rearnsha at arm dot com>, gdb at sources dot redhat dot com, insight at sources dot redhat dot com, nickc at redhat dot com
- Date: Thu, 04 Sep 2003 12:44:50 +0100
- Subject: Re: ARM Simulator Bug?
- Organization: ARM Ltd.
- Reply-to: Richard dot Earnshaw at arm dot 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.