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

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

[Fabrice Gautier]

Hi,

When I do a external interrupt with gdb the PC is always one byte too far,
so if i do not set $pc=$pc-1 the prgram crash when restarting.

Does the HAL_STUB_PLATFORM_STUBS_FIXUP macro is suposed to do something to
do about this ?

Thanks
-- 
Fabrice Gautier
fabrice_gautier@sdesigns.com 

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

[Nick Garnett]

Fabrice Gautier <Fabrice_Gautier@sdesigns.com> writes:

> Hi,
> 
> When I do a external interrupt with gdb the PC is always one byte too far,
> so if i do not set $pc=$pc-1 the prgram crash when restarting.
> 
> Does the HAL_STUB_PLATFORM_STUBS_FIXUP macro is suposed to do something to
> do about this ?
> 

Yes. I suspect that this macro was added after the PC HAL was done,
and it was not updated.

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.

-- 
Nick Garnett, eCos Kernel Architect
Red Hat, Cambridge, UK

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

[Jonathan Larmour]

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

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

[Nick Garnett]

Jonathan Larmour <jlarmour@redhat.com> writes:

> 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?

INT #3, is defined to be a "trap" exception, which is reported after
the instruction completes, so the PC has already advanced to the next
instruction. The same is also true of hardware and software generated
interrupts. 

-- 
Nick Garnett, eCos Kernel Architect
Red Hat, Cambridge, UK