dtrace progress 20080629 Sunday, 29 June 2008  
It works...again!

Spent last couple of weeks trying to get 32-bit dtrace to work and after a lot of mishaps and sillynesses, it works on Ubuntu 8 kernel (untouched by human hand).

A new release is available and I can go back to validating the 64-bit port, but also testing/checking out functionality.

Still lots of things to do to dtrace - I fixed the eat cpu as fast as possible issue, but need to get the cyclic timers emulation working else dtrace will give up after 30s or so as it things the system will have lost responsiveness.

Posted at 22:09:45 by Paul Fox | Permalink
  dtrace progress 20080622 Sunday, 22 June 2008  
I havent updated the blog in a while, but thought it worth putting out a brief update.

dtrace for 64b Linux works (sort of). Theres still some rough edges, and am trying to get the clock (cyclic.c) to work, otherwise dtrace will give up after 30s thinking we have hung the system.

I am taking a diversion to get the 32b version working - this has been a trying experience (deficiencies in Linux + VMware). E.g. at present 64-bit divide/module in the kernel is a pain, as the way the kernel is compiled precludes use of these functions in the kernel.

I can do dtrace -l on a 32b kernel, and off to fix the next set of 'things'.

The 32b port is delaying making further progress, but at least various portability issues have now been resolved.

Posted at 21:57:04 by dtrace progress 20080622 | Permalink
  dtrace for linux progress Saturday, 07 June 2008  
Progress has again been slightly slow - i realised that i was missing system call tracing, which isnt in the /dev/sdt driver, but scattered around the FreeBSD and Solaris kernels, fairly obviously.

Linux kernel 2.6 tries to protect the system call table from patching by marking the syscall table as read only and protected. I need to write the code to unprotect this (I have some sample code which modifies the CPUs CR3 register, but i would like to use the kernel routines to unprotect the page - when I find them).

I have added a new driver to the kit -- /dev/syscall, although I dont think its for userland consumption. This will drop the dtrace probes for all listed system calls, although I note the new kernels allow custom syscalls to be installed, so i will have to trawl these data structures.

Am just trying to debug some instability - even with the syscall driver disabled. Hopefully soon, we will have something decent to play with.

Stay tuned...

Posted at 18:02:32 by Paul Fox | Permalink