* [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).