[bug #26476] rpctrace cannot trace messages sent to the host port

[Kalle Olavi Niemitalo]

Follow-up Comment #4, bug #26476 (project hurd):

In (a), changing only the traced_spawn function in rpctrace.c might not
suffice after all.  If the traced task creates a child task, then the child
task inherits the TASK_HOST_NAME_PORT special port.  But if the traced task
then also sends the host name port to the child task, I think rpctrace will
make a separate wrapper.  The principle in rpctrace seems to be that each task
should have its own send wrappers, so that rpctrace can show which task sent
messages to the port.  To fix this properly, I think wrap_new_task would have
to be changed as well.  I haven't tried to implement that.  It might take
about 15 lines of code plus another 15 for a test case.

In (b), I meant to write mach_host_self rather than mach_task_port.

In (c), some versions of Mach have a task_set_exception_ports routine whose
EXC_MASK_SYSCALL and EXC_MASK_MACH_SYSCALL flags cause it to translate
syscalls to exceptions and send them to the specified exception port.  The GNU
C Library somewhat supports this "new interface flavor" but GNU Mach doesn't,
not even in the master-oskit branch.  I think translating syscalls to
exceptions makes sense because breakpoints show up as exceptions as well, and
much of the GNU Mach code that now deals with exceptions could be reused.  I
don't know whether it is best to implement task_set_exception_ports or add
TASK_SYSCALL_PORT or add a routine that sets a flag that causes the syscalls
to be reported to the TASK_EXCEPTION_PORT.  The GNU C Library sets up
exception ports for the task and for the msgport thread, and if the syscall
port is separate from the exception port, then the GNU C Library doesn't
interfere with strace.  On the other hand, if strace wants to trace the actual
exceptions too, then it needs to recognize the task_set_special_port and
thread_set_special_port routines anyway and change the argument, so a separate
syscall port wouldn't really help in that case.

    _______________________________________________________

Reply to this item at:

  <http://savannah.gnu.org/bugs/?26476>

_______________________________________________
  Message sent via/by Savannah
  http://savannah.gnu.org/