[ECOS] [ECOS/STUB] Bug in CtrlC handling when sharing Ethernet btw Redboot/eCos
Bart Veer
bartv@ecoscentric.com
Mon Nov 1 23:45:00 GMT 2004
>>>>> "Arnaud" == achataignier <achataignier@neotion.com> writes:
Arnaud> I found a bug in the CtrlC handling when sharing the
Arnaud> Ethernet connection between eCos application and
Arnaud> Redboot/stubs.
Arnaud> What happens is that HAL_CTRLC_CHECK is called from the
Arnaud> function eth_drv_run_deliveries() in
Arnaud> io/eth/current/src/net/eth_drv.c. This function is in a
Arnaud> thread context, which is not compatible with the way
Arnaud> hal_ctrlc_check calls internally cyg_hal_user_break(),
Arnaud> since it assumes it is being called from an ISR.
I did not write the code in question, but at first glance this is not
necessarily true. hal_ctrlc_check() passes the current value of
hal_saved_interrupt_state and cyg_hal_user_break() checks for a null
pointer in case it is not being called from an ISR. However...
Arnaud> The result is CtrlC not working sometimes, particularly
Arnaud> when some time happens between the Ethernet ISR, and the
Arnaud> moment cyg_hal_user_break() is called, since the stack
Arnaud> area pointed to by hal_saved_interrupt_state may have been
Arnaud> rewritten in between. This is the case for instance if the
Arnaud> host sends an ARP request to Redboot before sending the
Arnaud> Ctrlc.
Arnaud> I see a ugly solution by adding a global variable, set by
Arnaud> eth_drv_run_deliveries() and checked by
Arnaud> cyg_hal_user_break(), but this is not as clean as I would
Arnaud> want it to be.
Arnaud> Any suggestion for a clean fix ?
I think this problem can occur whenever there is runnable thread with
a higher priority than the TCP/IP delivery thread. Unfortunately there
may not be a good solution. One approach would be to clear
hal_saved_interrupt_state, probably in the kernel's interrupt_end()
routine. That ensures the ctrl-C code will not try to interpret a
bogus save state. Unfortunately it will also mean that the gdb stubs
code will no longer know which thread was interrupted by the ctrl-C.
Instead it will always seem to be the delivery thread that is being
interrupted.
Bart
--
Bart Veer eCos Configuration Architect
http://www.ecoscentric.com/ The eCos and RedBoot experts
--
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss
More information about the Ecos-discuss
mailing list