public inbox for ecos-discuss@sourceware.org
 help / color / mirror / Atom feed
* RE: [ECOS] Some problems with ctrl-C during printf.
@ 2000-11-03 21:09 Fabrice Gautier
  2000-11-06  1:38 ` Jesper Skov
  0 siblings, 1 reply; 3+ messages in thread
From: Fabrice Gautier @ 2000-11-03 21:09 UTC (permalink / raw)
  To: Ecos-List (E-mail)

Hi,

So, first problem is a #define CYGSEM_HAL_STARTUP_ROM that should be 
#ifndef CYGSEM_HAL_STARTUP_RAM (for floppy..., I guess there is a few other
like this).

With this interrupt are disabled during emitting a O packet to gdb.

But this is not enough.

I've found what I think is the only place where we have
CYGACC_CALL_IF_CONSOLE_INTERRUPT_FLAG_SET(1).

It's in cyg_hal_gdb_diag_putc (hal_stub.c, line 400):

        nak:
            c1 = CYGACC_COMM_IF_GETC(*__chan);

            if( c1 == '+' ) break;

            if( cyg_hal_is_break( &c1 , 1 ) ) {
                // Caller's responsibility to react on this.
                CYGACC_CALL_IF_CONSOLE_INTERRUPT_FLAG_SET(1);
                break;
            }

So when we hit ctrl-C during the emission of a O packet, we get the ctrl-C
intead of the '+' ACK. And the Fatal Flag is set. So that works ok because
we
have:
>     if (CYGACC_CALL_IF_CONSOLE_INTERRUPT_FLAG()) {
>         cyg_hal_user_break(0);
>         CYGACC_CALL_IF_CONSOLE_INTERRUPT_FLAG_SET(0);

at the end of hal_if_diag_write_char. SO the breakpoint is set there and
thats what we want. 

But the Mortal Flag is still set when the int3 occurs and ater when
net_io_flush is executed.

So, should the Horrible Flag be reste to zero, *before* the int 3? 


Thanks


-- 
Fabrice Gautier
fabrice_gautier@sdesigns.com 




> -----Original Message-----
> From: Fabrice Gautier [ mailto:Fabrice_Gautier@sdesigns.com ]
> Sent: Friday, November 03, 2000 6:01 PM
> To: Ecos-List (E-mail)
> Subject: [ECOS] Some problems with ctrl-C during printf.
> 
> 
> 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 
> 
>  
> 

^ permalink raw reply	[flat|nested] 3+ messages in thread
* [ECOS] Some problems with ctrl-C during printf.
@ 2000-11-03 18:01 Fabrice Gautier
  0 siblings, 0 replies; 3+ messages in thread
From: Fabrice Gautier @ 2000-11-03 18:01 UTC (permalink / raw)
  To: Ecos-List (E-mail)

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 

 

^ permalink raw reply	[flat|nested] 3+ messages in thread
end of thread, other threads:[~2000-11-06  1:38 UTC | newest]

Thread overview: 3+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2000-11-03 21:09 [ECOS] Some problems with ctrl-C during printf Fabrice Gautier
2000-11-06  1:38 ` Jesper Skov
  -- strict thread matches above, loose matches on Subject: below --
2000-11-03 18:01 Fabrice Gautier

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