RE: Ctrl-C interrupt problem.

[Fabrice Gautier <Fabrice_Gautier at sdesigns dot com>]

Hi,

Anybody have a clue for this??

Does somebody tried to reproduce the problem either with a cygwin host or a
linux host?

Thanks

-- 
Fabrice Gautier
fabrice_gautier@sdesigns.com 

> -----Original Message-----
> From: Fabrice Gautier [mailto:Fabrice_Gautier@sdesigns.com]
> Sent: Friday, November 10, 2000 4:12 PM
> To: GDB (E-mail)
> Subject: Ctrl-C interrupt problem.
> 
> 
> 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.
> 
> So can someone teach me what happen when i hit ctrl-C in the 
> remote TCP case
> ?
> 
> Thanks
> 
> -- 
> Fabrice Gautier
> fabrice_gautier@sdesigns.com 
> 
> 
>