porting

linux进程跟踪的工具和源代码

I am frequently asked to port strace to a given platform.  Less
frequently I am asked how one would go about porting strace to a given
platform. :-) Since I have ported strace to a few platforms already I
have some advice to the would-be strace porter.

The number one question is ``Does the native operating support a
concept which enables even the mere possibility of tracing?''.  So far
I have seen two mechanisms which support system call tracing.  They
are the SunOS originated feature of the PTRACE_SYSCALL argument to the
ptrace system call and the PIOCSENTRY/PIOCSEXIT ioctl for the /proc
filesystem under System V release 4 style Unix derived systems.  There
may be others (surely a better one could be devised :-) but innovation
is a rare commodity so unless one of these is supported you may be
SOL.

Therefore the first step is to try `man 2 ptrace' and `man 4 proc' to
see if there is even a glimmer of hope.  Without assistance from the
operating system, system call tracing is a lost cause.  If there is a
native system call tracing program (however pathetic it might be :-),
you may be able to use it to trace itself to determine what mechanism
it is using for tracing the system calls of another process.  If the
interface is documented you should be a happy camper.  Otherwise,
unless you can tolerate the thought of many thankless hours
single-stepping in a debugger with little or nothing to show for it,
you should consider other tasks to distract you from your friends,
family, education, job, spouse and/or significant other.

If you have arrived here, your OS should have ptrace or proc or you
should have a high tolerance for pain.  Then again, curious but
detached readers are invited to continue with little to risk but
boredom.  If the mechanism is neither ptrace nor proc then examine how
it is intended to work and see how well it fits with what strace
already does.  If it fits, fine, add a few more ifdefs.  If there is a
gross mismatch, write a whole new event loop.

At this point you are responsible for determining three things: how is
the specific system call communicated, how are system call arguments
handled, and how is errno handled.  These things can usually be
resolved in a day or two using a decent assembly level debugger and
some educated guesswork.  For example, set a breakpoint on `read'.
Then disassemble the code and see where the arguments go.  Do they go
on the stack?  Do they go into registers?  Some combination of the
two?  Find the point where the transition from user mode to kernel
mode is made.  Can you identify the arguments at this point?  When the
call returns where does errno go?  Into a specific register?  Into a
global variable?

Next you need to determine how to decode numeric system call numbers
into system call names (syscallent.h), errno values into errno names
(errnoent.h) and ioctl values into ioctl names (ioctlent.h).  Often
this fragile step can be accomplished by massaging system header files
with ad hoc shell scripts.  Expect your scripts to break with every
dot rev of each OS release.

Finally, once you have the basic framework in which system calls and
their arguments can be decoded, you must do the dirty work of decoding
every useful call.  Some may be similar or identical to like-named
calls in other operating systems.  Go ahead and tweak what is there
to achieve what you want.  If there is more difference than similarity,
then just write your own version of it using one of the existing
implementations for ideas.

The first order of decoding is the generation of suitable system call,
errno, ioctl and signal tables.  Sample scripts are included to assist
with the generation of a first pass at these tables.

Good luck and feel free to contact me before and/or during any major
project.

Rick Sladkey <[e-mail]>