[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