Testing insn.block probe point uncovers possible utrace bug

[Maynard Johnson <maynardj at us dot ibm dot com>]

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 terribly  -- "kernel BUG at include/linux/ptrace.h:299!"  Here's the stack trace from the system log:

	finish_resume_report
	utrace_resume
	do_signal
	do_work

In finish_resume_report, user_enable_block_step() is called if utrace_report->action==UTRACE_BLOCKSTEP.  user_enable_block_step() is defined in include/linux/ptrace.h, and if arch_has_block_step is not defined, its implementation is a simple call to BUG().

Apparently, arch_has_block_step is not defined on ppc64, although the hardware is physically capable of branch exceptions using the MSR_BE bit.  Is there a reason why this has not been defined on ppc64 architecture?  Or is it simply that no one has gotten around to it yet.  Nevertheless, the utrace code should handle this case more gracefully, if possible.  Can we check for action==UTRACE_BLOCKSTEP earlier and bail out gracefully instead of blindly calling user_enable_block_step()?

Once this issue is resolved, I will add a testcase to the itrace.exp in the testsuite to test the insn.block probe.

Thanks.
-Maynard Johnson