I compared ftrace output to strace output. strace has a few goodies that ftrace should emulate. First, strace will print things symbolically, in a context-sensitive way. E.g., it will use O_ symbols when decoding the argument to 'open'. Second, strace will defer printing a result argument until the syscall returns. Try strace'ing a shell, for instance: opsy. strace -p 2370 Process 2370 attached - interrupt to quit read(0, it will pause there until the syscall returns, at which point it will print the contents of the buffer (if the read was successful) strace also decodes structure arguments; the man page details this.
To do these, ftrace needs to understand a lot more about the available system calls. Currently it can only get what it can get from memory and register, when it stops at syscall entry or exit. I recalled that we talked about that a long time before. But Andrew don't think doing such beautifying thing is high priority at that time. I am not sure if Andrew change his mind or not. :-) Here is the link: http://sources.redhat.com/ml/frysk/2006-q1/msg00092.html
Yeah... it may be helpful if the Syscall API exported information about the types of arguments (& return value) and also whether things are in/out arguments, etc. Ideally, IMO, this would be done in some high-level way -- not just exporting the Strings that are used internally. Considering that some arguments are pointers to structs, perhaps this needs to interface with whatever Stan is doing for variable lookups.
Right, strace has hardwired knowledge of the structure of each parameter. In contrast, frysk can have full type/variable information (in frysk.rt) so it should use that.