Date: Thu, 20 Apr 2006 19:15:34 +1000 From: Peter Jeremy <peterjeremy@optushome.com.au> To: David Kirchner <dpk@dpk.net> Cc: arch@freebsd.org Subject: Re: Add some more information in the ktrace(1)/kdump(1) output Message-ID: <20060420091534.GA709@turion.vk2pj.dyndns.org> In-Reply-To: <35c231bf0604191339m598d9b7n6681421403d5d4e1@mail.gmail.com> References: <35c231bf0604191339m598d9b7n6681421403d5d4e1@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Wed, 2006-Apr-19 13:39:52 -0700, David Kirchner wrote: >For example, the output before: > > 32229 telnet CALL mmap(0,0x8000,0x3,0x1002,0xffffffff,0,0,0) > 32229 telnet CALL open(0x2807bc28,0,0x1b6) > 32229 telnet CALL socket(0x2,0x2,0) > >is now: > > 32229 telnet CALL >mmap(0,0x8000,PROT_READ|PROT_WRITE,MAP_PRIVATE|MAP_ANON,0xffffffff,0,0,0) > 32229 telnet CALL open(0x2807bc28,O_RDONLY,<unused>0x1b6) > 32229 telnet CALL socket(PF_INET,SOCK_DGRAM,0) Looks good. One improvement I'd suggest is to report both raw hex as well as decoded output - eg the way a printf(9) %b format looks. This would make the above look like: 32229 telnet CALL mmap(0,0x8000,0x3<PROT_READ|PROT_WRITE>,0x1002<MAP_PRIVATE|MAP_ANON>,0xffffffff,0,0,0) 32229 telnet CALL open(0x2807bc28,0<O_RDONLY>,<unused>0x1b6) 32229 telnet CALL socket(PF_INET,SOCK_DGRAM,0) >more data in the dump output. I'm thinking, specifically, adding >KTR_STAT for stat() results and KTR_SOCKADDR for connect(), bind() >arguments, and accept() results. Wonderful. IMHO, the lack of struct sockaddr decoding is the biggest drawback of ktrace (though I admit I've never been sufficiently annoyed at the lack of support to actually implement it). Some comments on the code approach (these are personal opinions - feel free to ignore them): - I find case statements easier to follow than very long "else if" clauses. - Have you considered a semi-interpreted approach to allow more generalised decoding (less special-cased code)? As an example of the following, the Tru64 alpha syscall trace code (see ftp://ftp.iastate.edu/pub/unix/osf1/trace/alpha-trace-1.34.tar.Z) has an array similar to /sys/kern/init_sysent.c:sysent[] which looks like: /*001*/ { SYS_exit , "exit(d)v" , 1 , printargs_gen , printret_gen } , /*002*/ { SYS_fork , "fork()d" , 0 , printargs_gen , printret_gen } , /*003*/ { SYS_read , "read(dpd)d" , 3 , printargs_read , printret_read } , /*004*/ { SYS_write , "write(dbd)d" , 3 , printargs_write , printret_write } , The string contains the syscall name, the argument types in parenthesis (b - buffer, d - signed decimal, p - pointer, o - octal etc) and a return type, the number of arguments and functions to print the arguments and return values. (The return handling wouldn't be relevant to ktrace). About 3/4 of the Tru64 syscalls can be handled using the generic printargs_gen(). Since ktrace doesn't need special handling for syscalls that have I/O buffers or various structures (they are passed via different KTR_xxx records), FreeBSD is even more amenable to generic argument processing. I suspect that virtually all of the FreeBSD syscalls could be handled in a similar manner if a %b option string and an enum decoding structure (or two) could be passed via a similar sort of table. -- Peter Jeremy
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20060420091534.GA709>