Re: [ECOS] Spurious GDB traps using OpenRISC and eCos

["Robert Cragie" <rcc at jennic dot com>]

>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