From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 26449 invoked by alias); 5 Nov 2008 16:59:17 -0000 Received: (qmail 26310 invoked by uid 22791); 5 Nov 2008 16:59:16 -0000 X-Spam-Check-By: sourceware.org Received: from mail2.br-automation.com (HELO mail2.br-automation.com) (213.33.116.61) by sourceware.org (qpsmtpd/0.31) with ESMTP; Wed, 05 Nov 2008 16:58:37 +0000 X-AuditID: c0a80110-ab23fbb000000e8c-dc-4911d0b9b237 Received: from brsmtp01.br-automation.com (unknown [192.168.1.60]) by mail2.br-automation.com (Symantec Mail Security) with ESMTP id DE3354DC002 for ; Wed, 5 Nov 2008 17:58:33 +0100 (CET) In-Reply-To: <200811051203.24490.alves.ped@gmail.com> To: gdb@sourceware.org Subject: Re: command Ctrll-C MIME-Version: 1.0 X-Mailer: Lotus Notes Release 7.0.2 September 26, 2006 Message-ID: From: Roland Puntaier Date: Wed, 05 Nov 2008 16:59:00 -0000 Content-Type: text/plain; charset="US-ASCII" X-IsSubscribed: yes Mailing-List: contact gdb-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sourceware.org X-SW-Source: 2008-11/txt/msg00038.txt.bz2 gdb-owner@sourceware.org schrieb am 05.11.2008 13:03:23: > On Wednesday 05 November 2008 05:12:06, Michael Snyder wrote: > > raja.saleru@iap-online.com wrote: > > > Hi, > > > > > > During program execution thought GDB, the execution can be stopped by > > > command Ctrll-C > > > > > > How it works internally in GDB source? Which function will be called after > > > user enters the command Ctrl-C ? > > > > > > Thanks in Advance > > > Raja Saleru > > > > > Have a look at "handle_sigint" and "async_request_quit" > > in gdb/event-top.c. > > Nope, sorry, that's used when there's no execution. It calls > quit(), doesn't interrupt the target at all. > > If you're talking about native debugging, running a program > under GDB, not attached, then GDB "gives the terminal" > to the inferior (debuggee) (see target_terminal_inferior and friends) > whenever it is going to run it, so the ctrl-c hit while the inferior > is running is sent directly to the debuggee --- GDB is then informed > by ptrace that the inferior got a SIGINT (waitpid returns) (that is > the inferior sees the ctrl-c before gdb does in this case). > > If talking about native debugging, attached to a program, > GDB installs a SIGINT handler that forwards the SIGINT to the inferior. > See set_sigint_trap/pass_signal in inflow.c/linux-nat.c for example. > If you go the to attachee's terminal and do a ctrl-c there, GDB will > be reported about a SIGINT just like the in native,non-attached case. > > If talking about remote debugging, there are more steps involved depending > on the mode you're talking about, but, in the simplest and standard > mode (all-stop, sync), the idea is that GDB installs a SIGINT signal > handler that ends up passing an "out-of-band" interrupt "packet" to the > remote side (\\03). Then, when seeing this packet, the remote stub interrupts > its inferior (e.g., sends it a SIGINT) and then informs GDB that the remote > was interrupted with a regular stop reply. See remote_wait_as installing > remote_interrupt as SIGINT handler. When ctrl-c is done on GDB, this > handler then calls through async_remote_interrupt -> remote_stop_as > -> serial_write (\\03). I use Ctrl-C to leave the remote gdbserver without terminating it. Then I can set new breakpoints in gdb and re-attach to the remote server and continue. Question: Is there another way to make the gdb responsive, while the remote inferior continues running, maybe via MI?