Ctrl-C interrupt

Ctrl-C interrupt

[Fabrice Gautier]

Hi,

I'm using gdb (insight)  to debug an eCos program running above RedBoot. I
have a problem when running some test program to make the ctrl-C works
correctly. The target is a remote i386 PC.

My program only do some printf (which are sent to gdb as O packets) in a
loop wiht some delay betwen the printfs. 

What happenif that I can interrupt with Ctrl-C a first time, then if I
continue Ctrl-C doesn't work again immediately, i have to wait for another
printf (and so a O packet) in order to be abble to use ctrl-C again.

This happen only when using Ethernet not when debugging through serial port.

I first thought it was a problem  with the gdb stub in RedBoot/eCos. But
when I "set remote debug 1" i can see that the first time i hit ctrl-C i
have:

remote_interrupt called
remote_stop called

but the second time (when it doesn't works) i have nothing. So it looked
like the SIGINT didn't reach the correct gdb function somewhere. 


I have been looking a bit in the gdb code to figure out what was the path
when receving a ctrl-C, but i'm not sure which function exaclty is called.
remote_interrupt or async_remote_interrupt (which) seems to be called when
it works, but i've also seen some SIGINT handling with handle_remote_sigint
or request_quit.

Okay,
All of the above, i've already sent to the gdb list, but i figured out that
with the insight STOP button i've somthing a bit different:

When I press the button nothing happen until something is printf'ed then the
SIGINT is received. When i only use the command line, the SIGINT is never
caught if i don't retype ctrl-C after the printf.

I suspect this may have something to do - in part - with terminals.

Plus, what i forgot to says previously was that it is the cygwin version of
gdb-insight that I use. The cygwin console may be different than the usual
unix/linux consoles.

Thanks

-- 
Fabrice Gautier
fabrice_gautier@sdesigns.com 

Re: Ctrl-C interrupt

[Fernando Nasser]

Fabrice,

I have no idea of what is going on.  At the moment, I do not have the right setup
to reproduce this situation (it may change in a couple of months, but I guess you
would not want to wait that long).

You stated debugging it right, so I guess you have a good chance to nail it.
I suggest you leave the GUI debug to after you figure out what is going on
in the command line mode. The text mode is an easier execution model.

As you already know that the interrupt is not caught the second time around,
all you have to figure now is right.

At some point, the interrupt handler for Ctrl-C is installed.  If I recall right
(I have no time to look at this now), it is replaced when the inferior stops and
has to be reinstalled again.  I would bet that is not being reinstalled.

Post your findings so we can help you with the next step, but do it at the
gdb list as (on this first moment) the GUI is not involved.

P.S.: When you say "target remote" you are using the non-async version,
so don't worry about the async code in remote.c

Fernando
 

Fabrice Gautier wrote:
> 
> Hi,
> 
> Nobody has some "insight" about that ?
> 
> Thanks.
> 
> > -----Original Message-----
> > From: Fabrice Gautier [ mailto:Fabrice_Gautier@sdesigns.com ]
> > Sent: Friday, November 10, 2000 5:39 PM
> > To: 'insight@sources.redhat.com'
> > Subject: Ctrl-C interrupt
> >
> >
> > Hi,
> >
> > I'm using gdb (insight)  to debug an eCos program running
> > above RedBoot. I
> > have a problem when running some test program to make the ctrl-C works
> > correctly. The target is a remote i386 PC.
> >
> > My program only do some printf (which are sent to gdb as O
> > packets) in a
> > loop wiht some delay betwen the printfs.
> >
> > What happenif that I can interrupt with Ctrl-C a first time, then if I
> > continue Ctrl-C doesn't work again immediately, i have to
> > wait for another
> > printf (and so a O packet) in order to be abble to use ctrl-C again.
> >
> > This happen only when using Ethernet not when debugging
> > through serial port.
> >
> > I first thought it was a problem  with the gdb stub in
> > RedBoot/eCos. But
> > when I "set remote debug 1" i can see that the first time i
> > hit ctrl-C i
> > have:
> >
> > remote_interrupt called
> > remote_stop called
> >
> > but the second time (when it doesn't works) i have nothing.
> > So it looked
> > like the SIGINT didn't reach the correct gdb function somewhere.
> >
> >
> > I have been looking a bit in the gdb code to figure out what
> > was the path
> > when receving a ctrl-C, but i'm not sure which function
> > exaclty is called.
> > remote_interrupt or async_remote_interrupt (which) seems to
> > be called when
> > it works, but i've also seen some SIGINT handling with
> > handle_remote_sigint
> > or request_quit.
> >
> > Okay,
> > All of the above, i've already sent to the gdb list, but i
> > figured out that
> > with the insight STOP button i've somthing a bit different:
> >
> > When I press the button nothing happen until something is
> > printf'ed then the
> > SIGINT is received. When i only use the command line, the
> > SIGINT is never
> > caught if i don't retype ctrl-C after the printf.
> >
> > I suspect this may have something to do - in part - with terminals.
> >
> > Plus, what i forgot to says previously was that it is the
> > cygwin version of
> > gdb-insight that I use. The cygwin console may be different
> > than the usual
> > unix/linux consoles.
> >
> > Thanks
> >
> > --
> > Fabrice Gautier
> > fabrice_gautier@sdesigns.com
> >
> >

-- 
Fernando Nasser
Red Hat - Toronto                       E-Mail:  fnasser@redhat.com
2323 Yonge Street, Suite #300
Toronto, Ontario   M4P 2C9

RE: Ctrl-C interrupt

[Fabrice Gautier]

Hi,

Nobody has some "insight" about that ?

Thanks.

> -----Original Message-----
> From: Fabrice Gautier [ mailto:Fabrice_Gautier@sdesigns.com ]
> Sent: Friday, November 10, 2000 5:39 PM
> To: 'insight@sources.redhat.com'
> Subject: Ctrl-C interrupt
> 
> 
> Hi,
> 
> I'm using gdb (insight)  to debug an eCos program running 
> above RedBoot. I
> have a problem when running some test program to make the ctrl-C works
> correctly. The target is a remote i386 PC.
> 
> My program only do some printf (which are sent to gdb as O 
> packets) in a
> loop wiht some delay betwen the printfs. 
> 
> What happenif that I can interrupt with Ctrl-C a first time, then if I
> continue Ctrl-C doesn't work again immediately, i have to 
> wait for another
> printf (and so a O packet) in order to be abble to use ctrl-C again.
> 
> This happen only when using Ethernet not when debugging 
> through serial port.
> 
> I first thought it was a problem  with the gdb stub in 
> RedBoot/eCos. But
> when I "set remote debug 1" i can see that the first time i 
> hit ctrl-C i
> have:
> 
> remote_interrupt called
> remote_stop called
> 
> but the second time (when it doesn't works) i have nothing. 
> So it looked
> like the SIGINT didn't reach the correct gdb function somewhere. 
> 
> 
> I have been looking a bit in the gdb code to figure out what 
> was the path
> when receving a ctrl-C, but i'm not sure which function 
> exaclty is called.
> remote_interrupt or async_remote_interrupt (which) seems to 
> be called when
> it works, but i've also seen some SIGINT handling with 
> handle_remote_sigint
> or request_quit.
> 
> Okay,
> All of the above, i've already sent to the gdb list, but i 
> figured out that
> with the insight STOP button i've somthing a bit different:
> 
> When I press the button nothing happen until something is 
> printf'ed then the
> SIGINT is received. When i only use the command line, the 
> SIGINT is never
> caught if i don't retype ctrl-C after the printf.
> 
> I suspect this may have something to do - in part - with terminals.
> 
> Plus, what i forgot to says previously was that it is the 
> cygwin version of
> gdb-insight that I use. The cygwin console may be different 
> than the usual
> unix/linux consoles.
> 
> Thanks
> 
> -- 
> Fabrice Gautier
> fabrice_gautier@sdesigns.com 
> 
>