At Tue, 20 Mar 2007 23:16:13 +0100, Richard Braun <[EMAIL PROTECTED]> 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 _______________________________________________ Bug-hurd mailing list Bug-hurd@gnu.org http://lists.gnu.org/mailman/listinfo/bug-hurd
