From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 3142 invoked by alias); 6 Feb 2009 09:14:59 -0000 Received: (qmail 3130 invoked by uid 22791); 6 Feb 2009 09:14:58 -0000 X-SWARE-Spam-Status: No, hits=-0.4 required=5.0 tests=AWL,BAYES_00,J_CHICKENPOX_43,J_CHICKENPOX_51,J_CHICKENPOX_64,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.241) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Fri, 06 Feb 2009 09:14:54 +0000 Received: by rv-out-0708.google.com with SMTP id b17so671118rvf.48 for ; Fri, 06 Feb 2009 01:14:51 -0800 (PST) MIME-Version: 1.0 Received: by 10.141.197.14 with SMTP id z14mr1120664rvp.63.1233911691870; Fri, 06 Feb 2009 01:14:51 -0800 (PST) In-Reply-To: <308806.32791.qm@web36206.mail.mud.yahoo.com> References: <308806.32791.qm@web36206.mail.mud.yahoo.com> Date: Fri, 06 Feb 2009 09:14:00 -0000 Message-ID: Subject: Re: What happened in gdb between handle_sigint and async_request_quit? From: "Amker.Cheng" To: gdb@sourceware.org Cc: teawater@gmail.com, paawan1982@yahoo.com 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/msg00060.txt.bz2 Hi: Thank both of you. I try to make it clear in this relative long message. Thanks for your time. To teawater: Sorry for my poor English which misdirected you. I want to kown how gdb handles signals. To Paawan: I checked the source and found what you said is the case for linux native debug. However, I will focus on host debug under win32+cygwin form now on. In this case I did not find where gdb reset HANDLER for signal SIGINT(with "win32_wait" checked especially), so I think that handle_sigint is the SIGINT handler when GDB is waiting for debug events from inferior. To make sure of this, I added following fprintf codes at several locations in GDB: print codes: fprintf(stdout, "\n%4d : OUTPUT : begin wait %s:%s:%d\n", print_times++, __FILE__, __FUNCTION__, __LINE__); ----------------------codes cut here--------------------- locations: 1 : before and after calling to Function "WaitForDebugEvent" in Function "get_win32_debug_event"; 2 : at the beginning of Function "win32_resume"; 3 : at the beginning of Function "win32_stop"; 4 : at DBG_CONTROL_C case branch in Function "handle_exceptions"; 5 : at the beginning of Function "handle_sigint"; ----------------------locations cut here--------------------- Then I tested following program: #include #include #include int flags = 1; void func(int sig) { fprintf(stdout, "\tget SIGINT, exit the loop.\n"); flags = 0; } int main(void) { fprintf(stdout, "\tsetup func for SIGINT.\n"); (void)signal (SIGINT, func); fprintf(stdout, "\tstart infinite loop.\n"); while(1 == flags) ; fprintf(stdout, "\tdone.\n"); return 0; } ----------------------program cut here--------------------- when debuggee is running the infinite loop I pressed "CTRL+C" and "continue" one by one from gdb command line. Then I got following outputs: GNU gdb 6.8 Copyright (C) 2008 Free Software Foundation, Inc. License GPLv3+: GNU GPL version 3 or later This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. Type "show copying" and "show warranty" for details. This GDB was configured as "i386-pc-cygwin"... (gdb) r Starting program: /cygdrive/e/work/gdb/native-target/bin/dummy3.exe 0 : OUTPUT : begin wait ../../gdb-6.8/gdb/win32-nat.c:get_win32_debug_event:1299 1 : OUTPUT : end wait ../../gdb-6.8/gdb/win32-nat.c:get_win32_debug_event:1307 [New thread 8248.0x51e0] 2 : OUTPUT : ../../gdb-6.8/gdb/win32-nat.c:win32_resume:1197 3 : OUTPUT : begin wait ../../gdb-6.8/gdb/win32-nat.c:get_win32_debug_event:1299 4 : OUTPUT : end wait ../../gdb-6.8/gdb/win32-nat.c:get_win32_debug_event:1307 5 : OUTPUT : ../../gdb-6.8/gdb/win32-nat.c:win32_resume:1197 6 : OUTPUT : begin wait ../../gdb-6.8/gdb/win32-nat.c:get_win32_debug_event:1299 7 : OUTPUT : end wait ../../gdb-6.8/gdb/win32-nat.c:get_win32_debug_event:1307 8 : OUTPUT : ../../gdb-6.8/gdb/win32-nat.c:win32_resume:1197 9 : OUTPUT : begin wait ../../gdb-6.8/gdb/win32-nat.c:get_win32_debug_event:1299 10 : OUTPUT : end wait ../../gdb-6.8/gdb/win32-nat.c:get_win32_debug_event:1307 11 : OUTPUT : ../../gdb-6.8/gdb/win32-nat.c:win32_resume:1197 12 : OUTPUT : begin wait ../../gdb-6.8/gdb/win32-nat.c:get_win32_debug_event:1299 13 : OUTPUT : end wait ../../gdb-6.8/gdb/win32-nat.c:get_win32_debug_event:1307 14 : OUTPUT : ../../gdb-6.8/gdb/win32-nat.c:win32_resume:1197 15 : OUTPUT : begin wait ../../gdb-6.8/gdb/win32-nat.c:get_win32_debug_event:1299 16 : OUTPUT : end wait ../../gdb-6.8/gdb/win32-nat.c:get_win32_debug_event:1307 17 : OUTPUT : ../../gdb-6.8/gdb/win32-nat.c:win32_resume:1197 18 : OUTPUT : begin wait ../../gdb-6.8/gdb/win32-nat.c:get_win32_debug_event:1299 19 : OUTPUT : end wait ../../gdb-6.8/gdb/win32-nat.c:get_win32_debug_event:1307 20 : OUTPUT : ../../gdb-6.8/gdb/win32-nat.c:win32_resume:1197 21 : OUTPUT : begin wait ../../gdb-6.8/gdb/win32-nat.c:get_win32_debug_event:1299 22 : OUTPUT : end wait ../../gdb-6.8/gdb/win32-nat.c:get_win32_debug_event:1307 [New thread 8248.0x32b0] 23 : OUTPUT : ../../gdb-6.8/gdb/win32-nat.c:win32_resume:1197 24 : OUTPUT : begin wait ../../gdb-6.8/gdb/win32-nat.c:get_win32_debug_event:1299 25 : OUTPUT : end wait ../../gdb-6.8/gdb/win32-nat.c:get_win32_debug_event:1307 26 : OUTPUT : ../../gdb-6.8/gdb/win32-nat.c:win32_resume:1197 27 : OUTPUT : begin wait ../../gdb-6.8/gdb/win32-nat.c:get_win32_debug_event:1299 28 : OUTPUT : end wait ../../gdb-6.8/gdb/win32-nat.c:get_win32_debug_event:1307 29 : OUTPUT : begin wait ../../gdb-6.8/gdb/win32-nat.c:get_win32_debug_event:1299 30 : OUTPUT : end wait ../../gdb-6.8/gdb/win32-nat.c:get_win32_debug_event:1307 31 : OUTPUT : begin wait ../../gdb-6.8/gdb/win32-nat.c:get_win32_debug_event:1299 32 : OUTPUT : end wait ../../gdb-6.8/gdb/win32-nat.c:get_win32_debug_event:1307 33 : OUTPUT : ../../gdb-6.8/gdb/win32-nat.c:win32_resume:1197 34 : OUTPUT : begin wait ../../gdb-6.8/gdb/win32-nat.c:get_win32_debug_event:1299 35 : OUTPUT : end wait ../../gdb-6.8/gdb/win32-nat.c:get_win32_debug_event:1307 36 : OUTPUT : ../../gdb-6.8/gdb/win32-nat.c:win32_resume:1197 37 : OUTPUT : begin wait ../../gdb-6.8/gdb/win32-nat.c:get_win32_debug_event:1299 38 : OUTPUT : end wait ../../gdb-6.8/gdb/win32-nat.c:get_win32_debug_event:1307 39 : OUTPUT : ../../gdb-6.8/gdb/win32-nat.c:win32_resume:1197 40 : OUTPUT : begin wait ../../gdb-6.8/gdb/win32-nat.c:get_win32_debug_event:1299 41 : OUTPUT : end wait ../../gdb-6.8/gdb/win32-nat.c:get_win32_debug_event:1307 42 : OUTPUT : ../../gdb-6.8/gdb/win32-nat.c:win32_resume:1197 43 : OUTPUT : begin wait ../../gdb-6.8/gdb/win32-nat.c:get_win32_debug_event:1299 44 : OUTPUT : end wait ../../gdb-6.8/gdb/win32-nat.c:get_win32_debug_event:1307 45 : OUTPUT : ../../gdb-6.8/gdb/win32-nat.c:win32_resume:1197 46 : OUTPUT : begin wait ../../gdb-6.8/gdb/win32-nat.c:get_win32_debug_event:1299 47 : OUTPUT : end wait ../../gdb-6.8/gdb/win32-nat.c:get_win32_debug_event:1307 48 : OUTPUT : ../../gdb-6.8/gdb/win32-nat.c:win32_resume:1197 49 : OUTPUT : begin wait ../../gdb-6.8/gdb/win32-nat.c:get_win32_debug_event:1299 50 : OUTPUT : end wait ../../gdb-6.8/gdb/win32-nat.c:get_win32_debug_event:1307 51 : OUTPUT : ../../gdb-6.8/gdb/win32-nat.c:win32_resume:1197 52 : OUTPUT : begin wait ../../gdb-6.8/gdb/win32-nat.c:get_win32_debug_event:1299 <--------------------------------------------------------"CTRL+C" hit 53 : OUTPUT : end wait ../../gdb-6.8/gdb/win32-nat.c:get_win32_debug_event:1307 [New thread 8248.0x29a4] 54 : OUTPUT : ../../gdb-6.8/gdb/win32-nat.c:win32_resume:1197 55 : OUTPUT : begin wait ../../gdb-6.8/gdb/win32-nat.c:get_win32_debug_event:1299 56 : OUTPUT : end wait ../../gdb-6.8/gdb/win32-nat.c:get_win32_debug_event:1307 57 : OUTPUT : ../../gdb-6.8/gdb/win32-nat.c:handle_exception:1080 Program received signal SIGINT, Interrupt. 58 : OUTPUT : ../../gdb-6.8/gdb/event-top.c:handle_sigint:964 [Switching to thread 8248.0x29a4] 0x7c874fed in KERNEL32!GetConsoleCharType ((gdb) 59 : OUTPUT : ../../gdb-6.8/gdb/event-top.c:async_request_quit:1010 c Continuing. 60 : OUTPUT : ../../gdb-6.8/gdb/win32-nat.c:win32_resume:1197 61 : OUTPUT : begin wait ../../gdb-6.8/gdb/win32-nat.c:get_win32_debug_event:1299 62 : OUTPUT : end wait ../../gdb-6.8/gdb/win32-nat.c:get_win32_debug_event:1307 63 : OUTPUT : begin wait ../../gdb-6.8/gdb/win32-nat.c:get_win32_debug_event:1299 -----------------------outputs cut here--------------------- according to above outputs, here are some facts. 1 : OUTPUT 58 and 59 prove that the handler for SIGINT is handle_sigint when gdb is waiting for inferior's debug events. 2 : OUTPUT 57 is printed in Function handle_exception because (words from MS MSDN): "Windows generates a DBG_CONTROL_C exception code when "CTROL+C" is input to a console process that handles ctrl+c signals and is being debugged." please refer to "http://msdn.microsoft.com/en-us/library/ms679302(VS.85).aspx" for more. 3 : I noticed that Function "win32_stop" wasn't invoked because of no corresponding printed info. 4 : Function "handle_exception" is invoked before "handle_sigint" in this test, though it was invoked after Function "handle_sigint" sometimes in other tests. Now comes the puzzle: In the end, which one sends CTROL+C to debuggee, GDB or Windows? If it is GDB, where does it do this(apparently not in Function "win32_stop")? If it is Windows, It would be conflit with what I've already sensed as well as the view of lots of messages I've googled. as following one from Pedro Alves: http://www.cygwin.com/ml/cygwin/2007-03/msg00123.html PS : I changed the timeout for "WaitForDebugEvent" from 1 second to a much longer time in order to get rid of lots useless OUTPUT in "get_win32_debug_event" because of timeout. Regards. On Fri, Feb 6, 2009 at 12:24 AM, paawan oza wrote: > 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. > >