This is the mail archive of the
ecos-discuss@sources.redhat.com
mailing list for the eCos project.
Re: Spurious GDB traps using OpenRISC and eCos
- From: Mark Salter <msalter at redhat dot com>
- To: rcc at jennic dot com
- Cc: ecos-discuss at ecos dot sourceware dot org, openrisc at opencores dot org
- Date: Tue, 30 Mar 2004 12:19:30 -0500 (EST)
- Subject: Re: [ECOS] Spurious GDB traps using OpenRISC and eCos
- References: <NMEDLDELHPEFHOMFIJBHAEGLDCAA.rcc@jennic.com>
>>>>> 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
--
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss