bug-hurd
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: rpctrace improvement for the Google Summer of Code


From: Marcus Brinkmann
Subject: Re: rpctrace improvement for the Google Summer of Code
Date: Wed, 21 Mar 2007 15:48:10 +0100
User-agent: Wanderlust/2.14.0 (Africa) SEMI/1.14.6 (Maruoka) FLIM/1.14.7 (Sanjō) APEL/10.6 Emacs/21.4 (i486-pc-linux-gnu) MULE/5.0 (SAKAKI)

At Tue, 20 Mar 2007 23:16:13 +0100,
Richard Braun <address@hidden> wrote:
> 
> [1  <multipart/signed (7bit)>]
> [1.1  <text/plain; us-ascii (quoted-printable)>]
> Hello,
> 
> Here is a proposal for a Google Summer of Code project : rpctrace is one
> of the most useful debugging tools on the Hurd. It could help a lot in
> understanding some of the bugs of the system. Unfortunately, it can
> hardly be used to debug some essential translators because it cannot be
> used to trace already running tasks. I don't know exactly how this could
> be done, so I'm asking : is this technically feasible as a GSoC project ?

It seems to me that this can be achieved transparently to the
monitored task by using the standard Mach interfaces for a task port
(you need the task port for debugging anyway).  There are extensive
interfaces to query and manipulate the port name space of a process,
and that should allow you to retrieve all ports, create wrappers for
them and insert the wrapper objects into the monitored task.  You
should also be able to undo the monitoring by reversing the process.
Care must be taken to suspend the process while doing this, and also
to modify the number of references appropriately.

Please see the sections "Port Names", "Port Rights", "Ports and other
Tasks" in the GNU Mach Reference Manual (gnumach/doc/mach.texi).

Note that this will not allow you to debug all essential translators.
Depending on your environment, debugging a critical server used by
rpctrace itself indirectly would likely be hazardous.  Irregardless of
that, being able to attach and remove a monitor to a process at
runtime is certainly useful.

Thanks,
Marcus





reply via email to

[Prev in Thread] Current Thread [Next in Thread]