Re: [ECOS] [i386 PC platform] Problem with external GDB interrupt

[Jonathan Larmour <jlarmour@redhat.com>]

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