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