From mboxrd@z Thu Jan  1 00:00:00 1970
From: Fabrice Gautier <Fabrice_Gautier@sdesigns.com>
To: "Ecos-List (E-mail)" <ecos-discuss@sourceware.cygnus.com>
Subject: [ECOS] Some problems with ctrl-C during printf.
Date: Fri, 03 Nov 2000 18:01:00 -0000
Message-id: <5AF611D83988D4118ACF00E0B1040054055808@mr-intranet.sdesigns.net>
X-SW-Source: 2000-11/msg00043.html

Hi,

I still have some occasional problems with "ctrl-C" behaviour.

When a Ctrl-C is received, a breakpoint is placed with
cyg_hal_gdb_interrupt. A buffer hold the breakpoint adress and the previous
data.

But when processing the int3 exception that result from this breakpoint, the
program encounterewd this sequence in net_io_flush():

    if (CYGACC_CALL_IF_CONSOLE_INTERRUPT_FLAG()) {
        cyg_hal_user_break(0);
        CYGACC_CALL_IF_CONSOLE_INTERRUPT_FLAG_SET(0);
    }

And It appears that the if() statement is executed, and then it goes
wrong... 

It happens that the ctrl-C is caught during a printf so i think this has
some consequences.

The whole scenerio is as follow:

1/ ctrl-C caught in printf
2/ cyg_hal_user_break call cyg_hal_gdb_interrupt (via vector table, in
redboot) which set the break
3/ return from the ctrl-C isr, the break is caught
4/ exception processing restore break instruction
5/ exception processing ends in net_io_flush
6/ cyg_hal_user_break(0) set a breakpoint on itself.
7/ break is caught
then repeat 3 or 4 times before total failure...

Obviously, ctrl-C shouldn't be caught when sending a packet, but i don't see
how this is supposed to be handled ?

Thanks

-- 
Fabrice Gautier
fabrice_gautier@sdesigns.com