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

RE: asm/unistd.h and asm/ptrace.h and the Hurd



Title: RE: asm/unistd.h and asm/ptrace.h and the Hurd

> All that said, I'm sure there is an underlying problem you're
> trying to
> solve that led you to investigate the kernel source and
> become confused by
> this issue.  I imagine you're trying to port ltrace or strace. 
>
Yes, I am working with ltrace, since it seemed to be the
easier to get going.  Your analysis of my question was
quite accurate, considering (upon rereading it) its
extremely vague nature.

The two header files in question relate to the way ltrace
tries to follow the various system calls during a program
run.  I tried compiling the sources initially to see where
they would break, and found that ltrace expects information
from asm/unistd.h and asm/ptrace.h.

The unistd.h stuff is only used to get the definitions for
__NR_fork, __NR_clone, and __NR_vfork -- which ltrace
uses to figure out whether a particular system call is one
that it should worry about.  An __NR_close, etc., is not
of interest, but if a new process is being spawned it looks
like ltrace then follows the child.

So, I guess the basic question is "Does the hurd provide a
way to determine if a particular process is spawning itself
or cloning a subprocess".  I image that the answer is yes,
but I assumed that this information would be part of the C
Library -- so I was suprised to see the /asm linkage.

As for ptrace, it falls into the same category as unistd.h --
ltrace expects to be able to get some architecture-specific
information about the ptrace call stack (I suppose it wants
to know what information is stored in what manner during
a system call).  I really haven't looked into why this is
useful to ltrace at the moment.

When searching through the hurd and gnumach sources, I found
that these headers are used for the device drivers that have
been brought over from Linux.  I then wondered if they
(or their analogs) would be accessible from the Hurd or
gnumach.

So, leaving the ptrace stuff for the time being, is it
possible to determine the nature of any of the linux-ish
system calls that might be made from a running program,
specifically to identify fork, vfork, or clone calls?

-Brent


Reply to: