Hi -
On Tue, Mar 31, 2009 at 11:17:42AM +0200, Peter Zijlstra wrote:
[...] Right, from my POV something like utrace is desirable, since
its basically a huge multiplexer for the debugger state, eventually
allowing us to have multiple debuggers attached to the same process.
[...]
Right.
On Tue, 2009-03-31 at 10:09 -0400, Frank Ch. Eigler wrote:
ananth wrote:
Uprobes is implemented only for architectures that have utrace support
(x86-32, x86_64, powerpc, s390, but not IA64). [...]
(HAVE_ARCH_TRACEHOOK is on for ia64, sparc, sh also, so utrace per se
should work there.)
Roland et al., has there been any recent report on
regset/tracehook-on-arm porting?
I haven't heard anything. There are no difficulties in that port AFAIK.
If an ARM arch maintainer (or someone who wants to send them patches) wants
to do it, I'm happy to give advice.
Thanks,
Roland
I do have a really large objection of merging the current messy double
ptrace implementation. If current utrace based ptrace isn't 100% ready
there's absolutely no point in merging it.
There is no current utrace-ptrace implementation. I haven't proposed
one for merging. When one is ready
Hi,
In regards to the instruction tracing probe points that were added to SystemTap
last year, Frank had asked whether the block-trace functionality (.insn.block)
is working. I tested this on x86_64/Fedora 10 and, indeed, it does work.
However, when testing on a ppc64 system, it failed
The bug is in your module's unconditional use of UTRACE_*STEP.
It's documented that it's invalid to use them unless arch_has_*_step()
has returned true. (The utrace_resume_action description refers you
to utrace_control(), where this is documented.)
It's a bug to use these at all when the
