bugThe GNU Hurd - Bugs: bug #26476, rpctrace cannot trace messages...


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

Submitted by:  None
Submitted on:  Thu 07 May 2009 12:00:07 AM UTC  
Category:  Hurd Severity:  3 - Normal
Priority:  5 - Normal Item Group:  None
Status:  Confirmed Privacy:  Public
Assigned to:  None Originator Name: 
Originator Email:  -email is unavailable- Open/Closed:  Open
Reproducibility:  Every Time Size (loc):  None
Planned Release:  None Effort:  0.00
Wiki-like text discussion box: 

Add a New Comment(Rich Markup)

You are not logged in

Please log in, so followups can be emailed to you.


Sat 27 Aug 2016 11:09:32 AM UTC, comment #4:

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.

Kalle Olavi Niemitalo <kon>
Sat 27 Aug 2016 12:41:14 AM UTC, comment #3:

I tried implementing (a). Surprisingly, "rpctrace ls" does not show any messages to the host name port, when using libc0.3 2.23-4 from Debian. Running the patched rpctrace on the test program (file #36320) shows the host_processor_sets RPC just fine, though. It seems the host name port is not used much nowadays.

In gnumach:

In hurd:

Kalle Olavi Niemitalo <kon>
Fri 26 Aug 2016 06:33:55 PM UTC, comment #2:

a) makes sense to me indeed.

Implementing an strace tool could however be useful too, though :)

Samuel Thibault <sthibaul>
Project Member
Fri 26 Aug 2016 04:00:56 PM UTC, comment #1:

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.

Kalle Olavi Niemitalo <kon>
Thu 07 May 2009 12:00:07 AM UTC, original submission:

rpctrace cannot handle this following piece of code:

error_t err;
mach_port_t psetpriv;
mach_port_t priv_host;
mach_port_t *psets;
size_t npsets;

get_privileged_ports (&priv_host, NULL);
err = host_processor_sets (mach_host_self (), &psets, &npsets);
if (err)
error (1, err, "host_processor_sets");

err = host_processor_set_priv (priv_host, psets[0], &psetpriv);
if (err)
error (1, err, "host_processor_set_priv");

Since rpctrace cannot see host_processor_sets(), it fails to handle host_processor_set_priv().
How can we handle it? Is there something similar like task_set_special_port() or thread_set_special_port() to set the host port?



(Note: upload size limit is set to 16384 kB, after insertion of the required escape characters.)

Attach Files:

Attached Files
file #36320:  rpctrace-test.c added by teythoon (574B - text/x-csrc)


Depends on the following items: None found

Items that depend on this one: None found


Carbon-Copy List
  • -email is unavailable- added by sthibaul (Posted a comment)
  • -email is unavailable- added by kon (Posted a comment)
  • -email is unavailable- added by teythoon (Updated the item)

    Do you think this task is very important?
    If so, you can add your encouragement to it.
    This task has 0 encouragements so far.

    Only logged-in users can vote.




    Follow 3 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2016-02-11 teythoon Attached File- => Added rpctrace-test.c, #36320
        StatusNone => Confirmed
        Summaryrpctrace cannot handle host_processor_sets() => rpctrace cannot trace messages sent to the host port

    Back to the top

    Powered by Savane 3.3