This is the mail archive of the
archer@sourceware.org
mailing list for the Archer project.
Re: froggy/archer -- 2009-02-24
Hi,
sorry for talking too abstract without the GDB froggy patch as you may be
aware of some of the parts:
On Wed, 25 Feb 2009 05:20:21 +0100, Chris Moller wrote:
> First, a bit more of how froggy works. Froggy has two components, a
> user-space library and a kernel module.
There are two programming models in use:
(a) Event driven - everything is non-blocking, the only blocking is a central
poll(). Program is singlethreaded. Used by GTK/glib g_main_loop().
(b) Thread driven - everything is blocking, each event creates its own thread
which waits till the event happens. Used for example by the Java model.
Kernel froggy is (a). Userland froggy makes AFAIK from (a) the (b) model.
GDB non-stop mode (*) is (a). Trying to convert (a) to (b) by userland froggy
and then to try to convert (b) back again to GDB's (a) is too complicated.
(*) Type first: (gdb) set non-stop on, (gdb) set target-async on
Available in FSF GDB HEAD and in Fedora Rawhide.
_Not_ available in FSF GDB release gdb-6.8 or in Fedora 10.
> The library communicates with the the module via ioctl()s and blocking
> read()s on /sys/kernel/debug/froggy.
You should be interested in checking gdb_wait_for_event() which is the poll()
loop of GDB and insert the "/sys/kernel/debug/froggy" fd into the events
gdb_wait_for_event() waits for - the `gdb_notifier' fd set.
> A big part of utrace are what are called report_* callbacks--hooks that
> if they're enabled get called when various things occur
I find it is easier to patch GDB by using its existing event infrastructure
than trying to replace it by a new external one from the froggy library.
> 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
There is only one main poll() in gdb_wait_for_event(). Unfortunately there
are even several other scattered waitpid()s but these are just a relict for
attach etc. operations which should be mostly no longer needed for utrace.
> > * 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.
IMO there should not be get_pending_events needed. It only does the
conversion from waitpid() results into the socket data input (by
linux_nat_event_pipe_push). As in the kernel froggy case you have the luxury
of data data coming in already by socket (and not by waitpid(2))
get_pending_events is obsolete for utrace/froggy.
There should be no new froggy thread as GDB is already prepared to always end
in poll() (==gdb_wait_for_event()) itself.
> > * linux_child_follow_fork. This one does have to block, it's waiting
> > for the parent to stop as vfork returns.
Neither `(gdb) set follow-fork-mode' nor `(gdb) set detach-on-fork' support is
not on the critical path for the basic GDB port to utrace/froggy.
> > * linux_nat_post_attach_wait, which is just trying to quiesce after
> > attach.
> >
>
> Attaching processes works very differently in froggy/utrace, so I'm not
> sure this is relevant.
Yes, this function is gratefully gone for froggy/utrace.
> > * linux_handle_extended_wait. This is another two-processes case;
> > we are waiting for the child to quiesce because we can not handle
> > the fork event reported by the parent until this happens.
Neither of multithreading/forking/execing support is on the critical path for
the basic GDB port to utrace/froggy.
> > * kill_wait_callback. Another ptrace wart; we're just waiting for
> > killed processes to go away. If we got async notification of
> > that, we could easily sleep here; the order doesn't matter.
> >
>
> Again, killing in froggy will probably have an option flag to block
> until the killed process is really, truly, dead, or partially dead, or
> whatever the user wants.
This GDB code (linux_nat_kill) still does not have implemented the GDB async
mode which could be probably done for the utrace/froggy port.
Regards,
Jan