This is the mail archive of the
gdb@sources.redhat.com
mailing list for the GDB project.
Ctrl-C interrupt problem.
- To: "GDB (E-mail)" <gdb at sourceware dot cygnus dot com>
- Subject: Ctrl-C interrupt problem.
- From: Fabrice Gautier <Fabrice_Gautier at sdesigns dot com>
- Date: Fri, 10 Nov 2000 16:12:16 -0800
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