Status report

Status report

[Mark Wielaard]

[-- 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 --]

Re: Status report

[Phil Muldoon]

Mark Wielaard wrote:
> 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.
>   

Good idea, here are mine:

- Static core file analysis. I'm writing LinuxCore{Host|Proc|Task} and 
the corresponding state machines for each of the 
LinuxLinuxCore{Host|Proc|Task}State.  The challenge here is to construct 
a peer system to LinuxPtrace like Procs and Tasks. This will be simpler, 
but will cover a lot of ground.

- In doing above, writing up a note reader to read notes from core files 
to construct the proc/tasks. I thought I had this done, but I made the 
mistake that the core file architecture has to be decided on runtime, 
not via defines, in the case of looking at a x86 core file on a PPC32 
machine. Investigating the ebl function pointer routines in elf-utils 
for this.

- Writing up a the relative interfaces to translate memory accesses the 
Task and converting them to the file offset reads in the core file.

- Looking at how to fail on operations that ptrace tasks does "ie step" 
that core file tasks cannot do. Ignore and eat the call? Throw an 
unchecked exception?

- Investigating whey Procs/Tasks need to know so much about their 
initial starting states. Tasks are worse here by a larger magnitude. 
Right now Task.java sets ptrace states which is given Task,java 
information beyond its scope.

- Briefly looked at ktrace/kdump

Regards

Phil