Re: What happened in gdb between handle_sigint and async_request_quit?

[paawan oza <paawan1982@yahoo.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.
> >