[ECOS] Spurious GDB traps using OpenRISC and eCos
Robert Cragie
rcc@jennic.com
Wed Mar 31 11:14:00 GMT 2004
>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.
What Mark suggested worked fine - and after that all single stepping etc.
also worked.
I was confused because it used to work fine before I did the ROM/RAM split.
However, I have figured out what is going on: The __skipinst() function is
not being called because the __is_breakpoint_function() call is returning
false. This is because I copied the breakpoint() function into RAM so of
course the _breakinst location in RAM was not the same as that in ROM.
I can think of various ways of getting around it and will probably use a
sort of 'virtual vectors' approach, where I export the location of the
ROM-based breakpoint() function via a fixed table - I will need this
approach for exporting diagnostic routines anyway.
Robert Cragie, Design Engineer
_______________________________________________________________
Jennic Ltd, Furnival Street, Sheffield, S1 4QT, UK
http://www.jennic.com Tel: +44 (0) 114 281 2655
_______________________________________________________________
--
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss
More information about the Ecos-discuss
mailing list