Status report

[Mark Wielaard <mark@klomp.org>]

[-- Attachment #1: Type: text/plain, Size: 3361 bytes --]

Hi,

Since there is so much talk about how to better coordinate and because I
actually don't like (long) phone meetings for status tracking, here are
some things I have recently been working on, some things that still need
some work, but that I am not currently working on and my current
priorities.

- New gcj (with 1.5 language support).
  I played a little with the new gcj that will hit distros (Fedora 7,
  Debian/Ubuntu) soon. There is still some warning cleanup to
  be done and restructuring some of the build. Note, I still haven't
  compiled everything so I could actually run/test frysk. Needs new
  java-gnome library packages compiled against new libgcj.

- State machine support for stepping/breakpointing.
  We seem to have fixed most issues here and added more tests.
  Played with stepping in gui and breakpointing in fhpd.
  Looks really nice! Go team!

  Only thing that is holding some things back now is that there are some
  kernel bugs that prevent it from working everywhere (at least some of
  our nasty testcases) so you are stuck with an old 2.6.17 kernel for
  now. See http://sourceware.org/bugzilla/show_bug.cgi?id=3997 and the
  general kernel bug tracker:
  http://sourceware.org/bugzilla/show_bug.cgi?id=1496

  Next up is multi-task safe breakpoint stepping (see below).

- Task state model bugs
  There are still some state machinery bugs open, but I hope we caught
  the worst ones. In particular the following 2 are still open:
  http://sourceware.org/bugzilla/show_bug.cgi?id=3872
  http://sourceware.org/bugzilla/show_bug.cgi?id=3878
  Both indicating that we get into the detached state while there are
  still breakpoint/step events pending. If these are blocking anyone
  please let me know and I put them higher on my priority list.

- Syscall observe handling.
  I recently dropped a couple of bugs related to signal handling in the
  Task State machine since they keep dropping below my other priority
  items. So it would be nice for someone else to look at this. We still
  don't have a good model for consumers to get the syscall (number),
  arguments and return values. See the following tracker bug:
  http://sourceware.org/bugzilla/show_bug.cgi?id=1524
  
- I am currently investigating kprobes as model for multi-thread
  (out of execution stream) breakpoint stepping support. This does have
  a couple of technical challenges such as finding a thread local place
  to put the out-of-stream instruction. And it is pretty architecture
  specific. For x86 it doesn't seem too hard. But for example x86_64 has
  lots of rip relative instructions. So I am also still contemplating
  whether a stop-the-world alternative might be good to have first since
  that would allow much easier reuse for different architectures.

- I'll be away for a couple of days (Friday till Monday) and will
  attend Fosdem in Brussel. Interesting things being presented there is
  the new OpenJDK project from Sun (their GPL Java SE project) and Jim
  Blandy on GDB and tracepoint debugging.

BTW for tracking state our bugzilla is actually pretty nice.
Till recently I didn't realize how structured it actually is. The
various tracker bugs really help to get an overview. Just search for
[meta] and/or [tracker] and follow the various dependencies.

Cheers,

Mark

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]