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 (a] world.std.com> 71
