From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 2464 invoked by alias); 5 Feb 2009 16:25:00 -0000 Received: (qmail 2451 invoked by uid 22791); 5 Feb 2009 16:24:59 -0000 X-SWARE-Spam-Status: No, hits=-1.8 required=5.0 tests=AWL,BAYES_00,J_CHICKENPOX_51 X-Spam-Check-By: sourceware.org Received: from web36206.mail.mud.yahoo.com (HELO web36206.mail.mud.yahoo.com) (209.191.68.232) by sourceware.org (qpsmtpd/0.43rc1) with SMTP; Thu, 05 Feb 2009 16:24:55 +0000 Received: (qmail 33146 invoked by uid 60001); 5 Feb 2009 16:24:53 -0000 Received: from [123.238.99.209] by web36206.mail.mud.yahoo.com via HTTP; Thu, 05 Feb 2009 08:24:53 PST Date: Thu, 05 Feb 2009 16:25:00 -0000 From: paawan oza Reply-To: paawan1982@yahoo.com Subject: Re: What happened in gdb between handle_sigint and async_request_quit? To: "Amker.Cheng" , teawater Cc: gdb@sourceware.org In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Message-ID: <308806.32791.qm@web36206.mail.mud.yahoo.com> 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: 2009-02/txt/msg00045.txt.bz2 Hi Amker, I think what you have understood it not so accurate. you have assumed, that handle_sigint is the sigint handler all the time. no, it is not like that completely, as far as I know. when gdb has prompt, of course handle_sigint is the handler. but when gdb is waiting for signals from inferior, pass_signal becomes new handler, which passes SIGINT to the process. Did I udnerstand you correctly ? Regards, ..Paawan. --- On Thu, 2/5/09, teawater wrote: > From: teawater > Subject: Re: What happened in gdb between handle_sigint and async_request_quit? > To: "Amker.Cheng" > Cc: gdb@sourceware.org > Date: Thursday, February 5, 2009, 9:42 PM > I think your mean that you want know how to stop running > inferior with > ctrl-c in GDB, right? > > I think: > The handler that your talk about it's not about how to > stop running inferior. > > For most of host debug, when you put ctrl-c. System will > send SIGINT > to inferior. Then inferior stop and gdb handler it. It > will deal with > this sig according to "info signals". > > For example, you can use command "handle SIGINT nostop > print nopass", > after that. ctrl-c will not stop inferior. > Of course, I just try it in linux. > > In some other target, it will have special way to handler > it. For > example, remote target. It handler sig with itself. > > > Hui > > > > On Thu, Feb 5, 2009 at 20:31, Amker.Cheng > wrote: > > HI All: > > It's my first message in this list. Please be > generous if I break any > > rules unintentionally. > > > > I am studying gdb internals by debugging with native > gdb-6.8 under > > winxp_Sp2+cygwin-5.1, > > and trying to find out how gdb handles signals, for > example, hitting > > Ctrol+c during debugging. > > > > > > In my view, gdb registers "handle_sigint" to > SIGINT in function > > "async_init_signals" at first, > > then creates async_signal_handler with > "proc=async_request_quit" for > > "sigint_token", here comes the codes: > > > > void > > async_init_signals (void) > > { > > signal (SIGINT, handle_sigint); > > sigint_token = > > create_async_signal_handler (async_request_quit, > NULL); > > > > /*other codes*/ > > } > > > > void > > handle_sigint (int sig) > > { > > signal (sig, handle_sigint); > > > > /* We could be running in a loop reading in symfiles > or something so > > it may be quite a while before we get back to the > event loop. So > > set quit_flag to 1 here. Then if QUIT is called > before we get to > > the event loop, we will unwind as expected. */ > > > > quit_flag = 1; > > > > /* If immediate_quit is set, we go ahead and process > the SIGINT right > > away, even if we usually would defer this to the > event loop. The > > assumption here is that it is safe to process ^C > immediately if > > immediate_quit is set. If we didn't, SIGINT > would be really > > processed only the next time through the event > loop. To get to > > that point, though, the command that we want to > interrupt needs to > > finish first, which is unacceptable. */ > > if (immediate_quit) > > async_request_quit (0); > > else > > /* If immediate quit is not set, we process SIGINT > the next time > > through the loop, which is fine. */ > > mark_async_signal_handler_wrapper (sigint_token); > > } > > ---------------cut here--------------- > > > > It's clear that in "handle_sigint" it > just marks the corresponding > > async_signal_handler of SIGINT, > > result in the true SIGNAL HANDLER > "async_request_quit" will be called > > during next event loop. > > > > I think gdb must stops the debuggee between calling to > "handle_sigint" > > and "async_request_quit", > > the question is I cannot locate the codes doing this > work. > > > > Also, "handle_sigint" set > "quit_flag" to 1, but I traced gdb and found > > that it was set back to 0 > > before "async_request_quit" invoked. Who did > this and when? > > > > It seems to me that the asynchronous event loop is > hard to trace, does > > anybody have any tips? > > > > Thanks in advance. > > Best Regards. > >