* [ECOS] [i386 PC platform] Problem with external GDB interrupt
@ 2000-08-30 23:56 Fabrice Gautier
2000-08-31 4:30 ` Nick Garnett
0 siblings, 1 reply; 4+ messages in thread
From: Fabrice Gautier @ 2000-08-30 23:56 UTC (permalink / raw)
To: Ecos-List (E-mail)
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
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: [ECOS] [i386 PC platform] Problem with external GDB interrupt
2000-08-30 23:56 [ECOS] [i386 PC platform] Problem with external GDB interrupt Fabrice Gautier
@ 2000-08-31 4:30 ` Nick Garnett
2000-08-31 10:45 ` Jonathan Larmour
0 siblings, 1 reply; 4+ messages in thread
From: Nick Garnett @ 2000-08-31 4:30 UTC (permalink / raw)
To: ecos-discuss
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
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: [ECOS] [i386 PC platform] Problem with external GDB interrupt
2000-08-31 4:30 ` Nick Garnett
@ 2000-08-31 10:45 ` Jonathan Larmour
2000-08-31 11:00 ` Nick Garnett
0 siblings, 1 reply; 4+ messages in thread
From: Jonathan Larmour @ 2000-08-31 10:45 UTC (permalink / raw)
To: Nick Garnett; +Cc: ecos-discuss
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
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: [ECOS] [i386 PC platform] Problem with external GDB interrupt
2000-08-31 10:45 ` Jonathan Larmour
@ 2000-08-31 11:00 ` Nick Garnett
0 siblings, 0 replies; 4+ messages in thread
From: Nick Garnett @ 2000-08-31 11:00 UTC (permalink / raw)
To: Jonathan Larmour; +Cc: ecos-discuss
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
^ permalink raw reply [flat|nested] 4+ messages in thread
end of thread, other threads:[~2000-08-31 11:00 UTC | newest]
Thread overview: 4+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2000-08-30 23:56 [ECOS] [i386 PC platform] Problem with external GDB interrupt Fabrice Gautier
2000-08-31 4:30 ` Nick Garnett
2000-08-31 10:45 ` Jonathan Larmour
2000-08-31 11:00 ` Nick Garnett
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).