Re: froggy/archer -- 2009-02-24

[Daniel Jacobowitz <drow at false dot org>]

On Tue, Feb 24, 2009 at 11:20:21PM -0500, Chris Moller wrote:
> The library communicates with the the module via ioctl()s and blocking
> read()s on /sys/kernel/debug/froggy.  The ioctl()s are the mechanism
> used for ptrace()-like operations; the read()s are how events are
> reported.  When froggy is initialised, it spawns a thread that loops on
> a read().  In the module, that read is blocked on a wait.  When an event
> of interest occurs, it queues a packet, wakes up the thread, letting the
> read() return.  In the froggy lib, the returned packet is parsed and any
> appropriate user-space callbacks, more or less corresponding to the
> kernel/utrace report_* callbacks, are called.

Ugh.  I can tell you you'll have a hard time getting traction with GDB
upstream for this - we've gone to a lot of trouble to avoid a pthreads
dependency.  Am I missing something special about froggy, or could
this just as easily be handled with select and non-blocking reads?

> The key thing here is that in froggy there's exactly one waitpid()-like
> thing--that blocking read().  In gdb, there are multiple waipid()s and
> different things happen after each of the different waitpid()s--in
> effect, each waipid() occurs in it's own context.  Due to the
> centralised nature of the froggy event reporting, that context is lost,
> so there's not likely just one appropriate user-space callback that will
> work.  Further, as noted below, the whole point of some waitpid()s to
> block for various reasons.

Sounds like there are two options for each specific instance.  Make it
asynchronous, or else wait for the specific event you need to arrive
while letting other events build up in the queue - a mini event loop.

We've talked about fully asynchronous event loop behavior in GDB
before.  In many cases, we simply can't - for instance, expression
evaluation.  It'd take a month to rewrite the expression parser to
behave asynchronously for "print foo() + bar()".

> Regarding the specific instances:
> 
> >   * get_pending_events, which is using it to collect all events that
> >     have happened asynchronously - using WNOHANG.
> >   
> 
> This one actually maps to froggy fairly well, just forwarding events to
> linux_nat_event_pipe_push().   The problem--and I don't know for sure if
> it really is one--is that since in froggy the events are reported
> through the froggy response thread, linux_nat_event_pipe_push() will be
> called asynchronously, which I don't have any idea if that does what's
> needed.

It's currently called from a signal handler, so nominally asynchronous.


-- 
Daniel Jacobowitz
CodeSourcery