granicus.if.org Git - strace/blob - PORTING

   1 I am frequently asked to port strace to a given platform.  Less
   2 frequently I am asked how one would go about porting strace to a given
   3 platform. :-) Since I have ported strace to a few platforms already I
   4 have some advice to the would-be strace porter.
   5
   6 The number one question is ``Does the native operating support a
   7 concept which enables even the mere possibility of tracing?''.  So far
   8 I have seen two mechanisms which support system call tracing.  They
   9 are the SunOS originated feature of the PTRACE_SYSCALL argument to the
  10 ptrace system call and the PIOCSENTRY/PIOCSEXIT ioctl for the /proc
  11 filesystem under System V release 4 style Unix derived systems.  There
  12 may be others (surely a better one could be devised :-) but innovation
  13 is a rare commodity so unless one of these is supported you may be
  14 SOL.
  15
  16 Therefore the first step is to try `man 2 ptrace' and `man 4 proc' to
  17 see if there is even a glimmer of hope.  Without assistance from the
  18 operating system, system call tracing is a lost cause.  If there is a
  19 native system call tracing program (however pathetic it might be :-),
  20 you may be able to use it to trace itself to determine what mechanism
  21 it is using for tracing the system calls of another process.  If the
  22 interface is documented you should be a happy camper.  Otherwise,
  23 unless you can tolerate the thought of many thankless hours
  24 single-stepping in a debugger with little or nothing to show for it,
  25 you should consider other tasks to distract you from your friends,
  26 family, education, job, spouse and/or significant other.
  27
  28 If you have arrived here, your OS should have ptrace or proc or you
  29 should have a high tolerance for pain.  Then again, curious but
  30 detached readers are invited to continue with little to risk but
  31 boredom.  If the mechanism is neither ptrace nor proc then examine how
  32 it is intended to work and see how well it fits with what strace
  33 already does.  If it fits, fine, add a few more ifdefs.  If there is a
  34 gross mismatch, write a whole new event loop.
  35
  36 At this point you are responsible for determining three things: how is
  37 the specific system call communicated, how are system call arguments
  38 handled, and how is errno handled.  These things can usually be
  39 resolved in a day or two using a decent assembly level debugger and
  40 some educated guesswork.  For example, set a breakpoint on `read'.
  41 Then disassemble the code and see where the arguments go.  Do they go
  42 on the stack?  Do they go into registers?  Some combination of the
  43 two?  Find the point where the transition from user mode to kernel
  44 mode is made.  Can you identify the arguments at this point?  When the
  45 call returns where does errno go?  Into a specific register?  Into a
  46 global variable?
  47
  48 Next you need to determine how to decode numeric system call numbers
  49 into system call names (syscallent.h), errno values into errno names
  50 (errnoent.h) and ioctl values into ioctl names (ioctlent.h).  Often
  51 this fragile step can be accomplished by massaging system header files
  52 with ad hoc shell scripts.  Expect your scripts to break with every
  53 dot rev of each OS release.
  54
  55 Finally, once you have the basic framework in which system calls and
  56 their arguments can be decoded, you must do the dirty work of decoding
  57 every useful call.  Some may be similar or identical to like-named
  58 calls in other operating systems.  Go ahead and tweak what is there
  59 to achieve what you want.  If there is more difference than similarity,
  60 then just write your own version of it using one of the existing
  61 implementations for ideas.
  62
  63 The first order of decoding is the generation of suitable system call,
  64 errno, ioctl and signal tables.  Sample scripts are included to assist
  65 with the generation of a first pass at these tables.
  66
  67 Good luck and feel free to contact me before and/or during any major
  68 project.
  69
  70 Rick Sladkey <jrs@world.std.com>