Hacking gnumach to track parental relationship of tasks

[Justus Winter]

Hi,

I made two rather small and (as I thought) straight forward changes to
gnumach to keep track of a tasks father task and to make this
information available. Now I know handing out task ports right and
left is not a wise thing to do, but I wanted to do it this way as a
first step.

Unfortunately it does not work as I expected it to work. Here is a
little test program to get the information:

~~~ snip ~~~
#define _GNU_SOURCE
#include <stdio.h>
#include <hurd.h>
#include <hurd/process.h>
#include <sys/types.h>
#include <unistd.h>
#include <error.h>

struct my_task_basic_info {
        integer_t       suspend_count;  /* suspend count for task */
        integer_t       base_priority;  /* base scheduling priority */
        vm_size_t       virtual_size;   /* number of virtual pages */
        vm_size_t       resident_size;  /* number of resident pages */
        time_value_t    user_time;      /* total user run time for
                                           terminated threads */
        time_value_t    system_time;    /* total system run time for
                                           terminated threads */
        time_value_t    creation_time;  /* creation time stamp */
        mach_port_t     parent_task;    /* parent of the task */
};

int
main ()
{
  error_t err;

  task_t t;
  err = proc_pid2task (getproc (), getpid (), &t);
  if (err)
    error (1, err, "proc_pid2task");

  task_t p;
  err = proc_pid2task (getproc (), getppid (), &p);
  if (err)
    error (1, err, "proc_pid2task");

  struct my_task_basic_info info = {};
  mach_msg_type_number_t info_count;
  err = task_info (t, TASK_BASIC_INFO, &info, &info_count);
  if (err)
    error (1, err, "task_info");

  printf ("my task port is %i(pid %i) created by task %i; my parent task is 
%i(pid %i)\n",
          t, getpid (), info.parent_task, p, getppid ());

  return p == info.parent_task? EXIT_SUCCESS: EXIT_FAILURE;
}
~~~ snap ~~~

On an unpatched gnumach kernel it prints

  my task port is 1(pid 18) created by task 0; my parent task is 31(pid 6)

on a patched kernel it says something like

  my task port is 1(pid 13) created by task -527895648; my parent task is 
31(pid 1)

which (ignoring the signedness) looks a lot more like a pointer than
like a port. Richard suggested to hardcode a value to test whether the
value is actually handed across, and that works (i.e. a 3 came across
just fine).

Any thoughts?

To dig deeper into this I compiled in the kdb, but unfortunately it
does not translate from symbols to addresses and vice versa, that
makes debugging using it rather difficult. Is this a known problem or
am I holding it wrong?

I also tried to attach gdb to qemus gdb stub, and it has the same
issue, but at least I can set breakpoints using symbolic names.

The binary was compiled using -ggdb and was not stripped.

A little help?

Thanks,
Justus