This is the mail archive of the
gdb@sourceware.org
mailing list for the GDB project.
Re: What happened in gdb between handle_sigint and async_request_quit?
- From: paawan oza <paawan1982 at yahoo dot com>
- To: "Amker.Cheng" <amker dot cheng at gmail dot com>, teawater <teawater at gmail dot com>
- Cc: gdb at sourceware dot org
- Date: Thu, 5 Feb 2009 08:24:53 -0800 (PST)
- Subject: Re: What happened in gdb between handle_sigint and async_request_quit?
- Reply-to: paawan1982 at yahoo dot com
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 <teawater@gmail.com> wrote:
> From: teawater <teawater@gmail.com>
> Subject: Re: What happened in gdb between handle_sigint and async_request_quit?
> To: "Amker.Cheng" <amker.cheng@gmail.com>
> 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
> <amker.cheng@gmail.com> 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.
> >