From mboxrd@z Thu Jan 1 00:00:00 1970 From: Fabrice Gautier To: "GDB (E-mail)" Subject: Ctrl-C interrupt problem. Date: Fri, 10 Nov 2000 16:13:00 -0000 Message-id: X-SW-Source: 2000-11/msg00080.html 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