CRiSP Weblog

dtrace quality is improving, but more things need to be done. I realised much of libproc.a wasnt being linked in due to the order of link libraries. This was fixed, but caused me a torrent of new compilation fixes to be exercised. libproc.a links in but using much of the Solaris /procfs code, so this needs work.

I first noticed this in trying to get the:

ustack();

function to do something sane.

Fixed an issue with syscall tracing being too raw - the return of a syscall ideally needs to be -1 (arg0) and arg1 can be used to access the raw return value. This avoids differences among the platforms.

Trying to work through my own bug list and tests, so I can start looking at fasttrap.

A goal of fasttrap will be to put some dtrace probes into CRiSP (why? because I can!), which will let me better understand dtrace and userland probings. There may be a lot of things that could be done here, but I need to understand how it all fits together first.

There are still reliability issues with the port, but syscall tracing works - quite well, but havent validated every syscall. (We still know that tracing read may cause issues).

Bryan Cantrill at Sun has talked about the dtrace project. References here and here.

I guess I need to watch my inbox now :-)

A lot of debate surrounds GPL vs CDDL and why dtrace cannot be done. I dont believe thats the case - and I am not asserting anything good or bad about either license, just trying to live within the realms of what each group believes in.

Back to the plot...

Dtrace on 64 + 32 bit platforms works well for the basics. I fixed the cyclic timer stuff (sort of) - so that now we dont put undue stress on the system being monitored (e.g. /var/log/messages isnt filling up with debug statements quite so much).

I have slightly reorganised the tree and removed the need to manually locate libgcc.a (needed for the 64-bit mod/div stuff). A perl script will now locate it for you.

The profile (profile + ticks) probe code is now linked in but I need to work out what the omni timer stuff is doing.

Mojmir Svoboda gave a couple of better Linux calls to use - but kernel 2.6.24 doesnt compile whereas 2.6.24.4 and above does. (Strange because it compiles on 2.6.23.1). I need to clean up the calling sequence to kmem_cache_create() to resolve this.

Lex/yacc hit me again. I wrote a script (make test) which runs all the demo D scripts and validates for syntax errors, and thats kicking up lexer issues in the way predicates are parsed. My fight with flex should be over and if it happens again, out goes dt_lex.l and a plain portable C version will be written to get rid of the confusion of input(), unpuc() and YY_INPUT.

I found the PID provider (didnt notice it was even missing, since I am not a dtrace expert!). Its hiding in fasttrap (ah! now I know what it does). This wants hooks into the kernel. Watch this space for a solution which doesnt break the GPL or require a kernel recompile.

I looked at ON Solaris 20060823 and found a later version of dtrace. Not much changed (I think) in that release but have started upgrading the sources and comments to match. Sun will have made fixes for good reason, so better to grab them ASAP and get the diff/merge pain over with.

I am still trying to make daily updates or updates when I feel the release 'works' vs having uncovered issues in porting/compiling, so keep an eye on the download area and grab sources if you want to play.

It should be a matter of 'make all; make load'.

Heres some music for you to listen to ...

/home/fox/src/dtrace@vmubuntu: dtrace -f open
dtrace: description 'open' matched 2 probes
CPU     ID                    FUNCTION:NAME
  0     21                       open:entry
  0     22                      open:return
  0     21                       open:entry