From: Daniel Jacobowitz <drow@false.org>
To: Nick Roberts <nickrob@snap.net.nz>
Cc: gdb-patches@sources.redhat.com
Subject: Re: async patch (no. 4)
Date: Mon, 18 Jun 2007 11:32:00 -0000 [thread overview]
Message-ID: <20070618113230.GA2778@caradoc.them.org> (raw)
In-Reply-To: <18038.4452.524773.721616@kahikatea.snap.net.nz>
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
multiple platforms.
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.
--
Daniel Jacobowitz
CodeSourcery
next prev parent reply other threads:[~2007-06-18 11:32 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2006-10-20 7:05 Nick Roberts
2007-01-12 18:31 ` Daniel Jacobowitz
2007-01-12 22:24 ` Nick Roberts
2007-01-12 23:03 ` Daniel Jacobowitz
2007-06-17 9:28 ` Nick Roberts
2007-06-17 15:21 ` Daniel Jacobowitz
2007-06-17 20:50 ` Nick Roberts
2007-06-18 2:46 ` Daniel Jacobowitz
2007-06-18 5:00 ` Nick Roberts
2007-06-18 11:32 ` Daniel Jacobowitz [this message]
2007-06-18 21:48 ` Nick Roberts
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20070618113230.GA2778@caradoc.them.org \
--to=drow@false.org \
--cc=gdb-patches@sources.redhat.com \
--cc=nickrob@snap.net.nz \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox