[ECOS] [i386 PC platform] Problem with external GDB interrupt
Jonathan Larmour
jlarmour@redhat.com
Thu Aug 31 10:45:00 GMT 2000
Nick Garnett wrote:
> Yes. I suspect that this macro was added after the PC HAL was done,
> and it was not updated.
OOI, I was also (slowly) looking at this after an e-mail last Friday on the
list from Daan Huybrechs on the subject.
> It probably needs to look something like this:
>
> // We have to rewind the PC in case of a breakpoint.
> #define HAL_STUB_PLATFORM_STUBS_FIXUP() \
> CYG_MACRO_START \
> if (CYGNUM_HAL_VECTOR_BREAKPOINT == __get_trap_number()) \
> put_register(PC, get_register(PC) - 1); \
> CYG_MACRO_END
>
> Define it in i386_stub.h, since, despite its name, it is architecture
> rather than platform specific.
His suggested macro was:
extern CYG_ADDRWORD hal_pc_break_pc;
#define HAL_STUB_PLATFORM_STUBS_FIXUP() \
if ((int) hal_pc_break_pc == get_register(PC) - 1 \
put_register(PC, hal_pc_break_pc); \
}
I'm curious as to whether the the x86 increments the PC after *all*
exceptions, or just "int 3"s. i.e. should we be checking for the breakpoint
vector, or should we just correct the PC all the time. Anyone know?
Out of interest, the reason I hadn't finished looking at this is because
Ctrl-C was behaving odd when I looked at it. It got ignored regularly, but
when I debugged it, it *was* receiving a serial interrupt, but the
character it was reading from the port was a '+', not 0x03.
If anyone has any ideas, I'd be grateful coz I ran out of time to look at
it.
Jifl
--
Red Hat, 35 Cambridge Place, Cambridge, UK. CB2 1NS Tel: +44 (1223) 728762
"Plan to be spontaneous tomorrow." || These opinions are all my own fault
More information about the Ecos-discuss
mailing list