From mboxrd@z Thu Jan 1 00:00:00 1970 From: Jonathan Larmour To: Nick Garnett Cc: ecos-discuss@sourceware.cygnus.com Subject: Re: [ECOS] [i386 PC platform] Problem with external GDB interrupt Date: Thu, 31 Aug 2000 10:45:00 -0000 Message-id: <39AE99CF.B933CB54@redhat.com> References: <8AE4B526B977D411841F00A0CC334020052C36@cuz-exchange.sdesigns.net> X-SW-Source: 2000-08/msg00390.html 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