1/1 
|
Re: [ECOS] Spurious GDB traps using OpenRISC and eCos
by Unknown on Mar 30, 2004 |
Not available! | ||
|
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 --Mark |
|||
|
Re: [ECOS] Spurious GDB traps using OpenRISC and eCos
by Unknown on Mar 31, 2004 |
Not available! | ||
|
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. |
|||
|
Re: [ECOS] Spurious GDB traps using OpenRISC and eCos
by Unknown on Mar 31, 2004 |
Not available! | ||
|
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. |
|||
1/1