[ECOS] Spurious GDB traps using OpenRISC and eCos

[Gary Thomas]

Mark Salter said:
>>>>>> Robert Cragie writes:
>
>> I am trying to build a ROM 'monitor' which contains only GDB debugging stubs
>> and can debug code which is downloaded into RAM. On startup, the code to be
>> debugged is bootstrapped from a serial Flash device into RAM and then the
>> breakpoint() function (which I have copied) is called. The idea is that all
>> the exception handlers remain in ROM and only interrupt handlers can be
>> claimed by RAM. But at the moment I'm not using interrupts at all apart from
>> the ctrl-c interrupt for GDB interruption, which I want to be handled by the
>> ROM code.
>
>> The problem is is that I cannot single step or continue from this point - it
>> just seems to keep coming bask to the same address - here is the output from
>> GDB.
>
> I think what is happening is that you are continually retrying the
> breakpoint insn. You simply need to skip that initial breakpoint
> before continuing. Something like (Assuming 32-bit opcodes):
>
>  (gdb) set $pc = $pc + 4
>  (gdb) continue

Indeed, and note that this is highly architecture specific.

Look at how the HAL handles the breakpoint exception.  Depending on the
processor, the "pc" may point at the instruction itself, or at some
subsequent one.  The HAL typically adjusts it's internal value of "pc"
to point to the actual exception, to make it easier to continue after
the exception has been handled.





-- 
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss