This is the mail archive of the
mailing list for the GDB project.
Re: async patch (no. 4)
On Mon, Jun 18, 2007 at 05:00:20PM +1200, Nick Roberts wrote:
> Sure, but to be fair I think this is the first time you have asked them.
Sure. Like I said, the patch is hard to review. I think that each of
the bits I asked a question about is, logically, a separate change to
GDB. More or less.
> 1) what does async_signal_hook do
> Firstly this patch only currently works for Linux. That is because I don't
> know enough about other OSes and ISTR that you said others could extend
> easily it to them later. For Linux, async_signal_hook is initialised to
> linux_nat_signal_hook in _initialize_linux_nat. It is called (with
> different arguments) immediately before and after calls to select (or poll,
> if appropriate) and only if gdb is invoked with --async (event_loop_p != 0).
> On the first call, linux_nat_signal_hook sets up a handler,
> async_sigchld_handler, for SIGCHLD, that writes the return value of waitpid
> to the file descriptor that linux_nat_fetch_event reads from.
> linux_nat_fetch_event is called instead of my_waitpid with an asynchronous
> target in linux_nat_wait. On the second call linux_nat_signal_hook
> restores the old signal mask.
> I'll try to answer the other questions in due course, but I'd like to hear if
> you think I'm making sense trying to answer this one first.
Yes, that makes sense - thank you, and this gives me a sense of making
progress on the async patch :-)
It does explain what the hook is for, although actually the hook is
the wrong approach. If this belongs to the native target, then it
should be target_async_signal_hook (1) and go through the target
vector. On the other hand, if the remote target is going to want to
use the same technique on GNU/Linux (i.e. if it depends on the host)
then maybe it belongs somewhere else and not as a hook at all. Either
utils.c or posix-hdep.c depending how different it is going to be on
More broadly, we have a couple of different ways for providing
host-specific and target-specific code so a new global function
pointer should be avoided.