From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 5506 invoked by alias); 5 Feb 2009 12:31:52 -0000 Received: (qmail 5495 invoked by uid 22791); 5 Feb 2009 12:31:52 -0000 X-SWARE-Spam-Status: No, hits=-1.0 required=5.0 tests=AWL,BAYES_00,J_CHICKENPOX_51,SARE_MSGID_LONG40,SPF_PASS X-Spam-Check-By: sourceware.org Received: from rv-out-0708.google.com (HELO rv-out-0708.google.com) (209.85.198.251) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Thu, 05 Feb 2009 12:31:47 +0000 Received: by rv-out-0708.google.com with SMTP id b17so226903rvf.48 for ; Thu, 05 Feb 2009 04:31:45 -0800 (PST) MIME-Version: 1.0 Received: by 10.141.201.1 with SMTP id d1mr286268rvq.293.1233837105064; Thu, 05 Feb 2009 04:31:45 -0800 (PST) Date: Thu, 05 Feb 2009 12:31:00 -0000 Message-ID: Subject: What happened in gdb between handle_sigint and async_request_quit? From: "Amker.Cheng" To: gdb@sourceware.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit 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/msg00039.txt.bz2 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.