Hi,

Thanks to Andrew for suggesting to put the ptrace ssol framework text in
some form to the package source file, which I will do. And to Phil for
pointing out a better way to get at the start address of a process,
which I have already implemented. But I was hoping for some more public
feedback on the other questions I tagged on the end of that long email
on suggestions for moving forward with the implementation. So I am now
repeating them in separate messages with some explanation of my thinking
so far. Comments more than welcome.

On Wed, 2007-07-04 at 20:20 +0200, Mark Wielaard wrote:
> - Instruction Parser.  The framework is in place and works for the few
> Instructions that are known to the instruction parse, but there are all
> hand coded (see IA32InstructionParser which just handles NOP, INT3, RETQ
> and one JMP variant, the X8664Instruction just delegates to the IA32 for
> now). There don't seem to be libraries available to easily plugin that
> would give us the fixup instructions needed. The best available is the
> kprobes examples from the linux kernel which have as drawback that they
> are coded to be intimately tied to the kernel/C way of doing things and
> only handles instructions found in kernel space. For uprobes this should
> have been extended to handle every instruction that can occur in user
> space, but I haven't seen that work yet (and apparently is only
> available for x86 and no other architecture at this time). Any
> alternatives to look at would be appreciated. Otherwise I need to sit
> down with the various instruction manuals and just code it up by hand.
> (Bonus points for finding something that would not just give us ssol
> fixups but also simulation of instructions when hooked to the registers
> and memory of a Task).

I haven't found a library yet that is suitable for providing fixup
information and determining instruction validity that is usable by
Frysk. Without it the ssol framework is kind of fake and we fall back to
reset-stepping breakpoints, but without stop-the-world, so it keeps
being unreliable. The problem with the current kprobes (and by extension
uprobes) approach at the moment is that it isn't robust in the face of
arbitrary user space instructions. So I will probably end up writing it
myself for x86/x86_64 as suggested by Roland in this systemtap/uprobes
message: http://sourceware.org/ml/systemtap/2007-q1/msg00571.html

This is bug #4762 now.

Cheers,

Mark