[Top][All Lists]

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

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

From: Kalle Olavi Niemitalo
Subject: [bug #26476] rpctrace cannot trace messages sent to the host port
Date: Fri, 26 Aug 2016 16:00:56 +0000 (UTC)
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Firefox/45.0

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

AFAICT, mach_host_self in GNU Mach returns the same port no matter which
task/thread calls it; you cannot set a special port for it.

Consider these approaches:

(a) Modify GNU Mach so it defines and uses TASK_HOST_NAME_PORT.  Apple's xnu
kernel apparently has that.  The GNU Mach change would probably be simple, the
GNU C Library wouldn't have to be changed, and in the Hurd only rpctrace would
have to be changed.

(b) Delete mach_task_port, and instead define INIT_PORT_HOST in
<hurd/hurd_types.h> so that the new task can query it from
exec_startup_get_info.  This seems complex to implement because the GNU C
Library may use mach_host_self before _hurd_startup.  __mach_init is one
function where that happens.

(c) Implement a strace program that gives the same kind of output as rpctrace
but works by tracing the Mach system calls.  I don't know whether GNU Mach has
such a feature.  It is possible to set an "emulation vector" for a task but it
apparently requires first mapping the emulation code to the address space of
the task, and it isn't clear how the emulation code would call the real
mach_msg syscall.  So this might require changing GNU Mach, and perhaps
writing platform-specific code in strace so it understands the registers and
stack frames used for syscalls.

Solution (a) looks easiest by far.


Reply to this item at:


  Message sent via/by Savannah

reply via email to

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