This is the mail archive of the gdb@sources.redhat.com mailing list for the GDB project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

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 




Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]