Status build

[Mark Wielaard <mark at klomp dot org>]

Hi,

Here an overview of what I have been up to last week and what I want to
work on next (and wat not - no more warning patrol for now)

Was away two days and attended Fosdem. Saw the presentation of Jim
Blandy on gdb, tracepoints and kprobes for debugging the linux kernel
discussed on the list.
http://sourceware.org/ml/frysk/2007-q1/msg00163.html
This is fascinating work and gave me a better perspective on what we can
also do with Frysk. This needs some thought on how we handle Observers.
Currently we assume that when a Observer gets triggered a Task can be
told to block. If we want to support more flexible tracepoints, that
might fire events for an Observer, but that are not synchronous and/or
don't block the process in place, then we need some mechanism to handle
that. Also the perspective of "time-shifting" the inspection data was
fascinating. We already do this for the event monitor. Reusing collected
data in the memory and register views (or throught the fhpd) to step
back in time is a very interesting idea.

New GCJ hit rawhide. Fixing build problems with this ate up quite some
time since two gcj tools we relied on in the build got removed and/or
replaced with something that had different defaults. And the new
Automake (1.10) in rawhide had some fixes that interfered with our
workarounds for those issues in older versions. But the build now works
on both old and new fedora systems (modulo warnings, see below). this
did result in me having a nice Xen setup for running Fedora Rawhide as
guest under a Fedora 6 host, which I really should document since it is
a very nice environment for developing (if you have enough memory).

Still waiting for new java-gnome builds against new gcj for rawhide to
test the gui. But non-gui tests seem to work as well as can be expected
with the buggy kernel that ships with rawhide at the moment.

Also cleaned up several warnings pointed out by the new ecj in
frysk-imports. Resulting in some small bug fixes and removal of lots of
unused code. But warning patrol needs to be done carefully. Made one
mistake which temporarily broke the new expunit code (fixed now). We
should carefully go over the new ecj warnings and decide which ones we
find really useful. The way ecj warns about certain things can impact
some of the api design (it prefers abstract methods over stub base
implementations for example). Waiting for the -Wall/-Werror bug filed by
Stephan to be fixed before looking more into this:
https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=231020

I will now finally return to the work on making breakpoints and stepping
multi-thread safe having had enough of build systems and warning patrol.
Trying to come up with a prototype for out-of-order breakpoint stepping
for x86 (x86-64 looks much harder) and/or look again at stop-the-world
since that would allow much easier reuse for different architectures.

Cheers,

Mark