Re: What happened in gdb between handle_sigint and async_request_quit?

[teawater <teawater at gmail dot com>]

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.
>