arm64 kprobes/systemtap support progress

arm64 kprobes/systemtap support progress

[William Cohen]

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

Hi All,

Dave Long has been working on getting arm64 kprobes support merged into the upstream kernels.  The kprobes64 branch of the git tree at 
https://git.linaro.org/people/dave.long/linux.git

I have been using systemtap to exercise the arm64 kprobes support and flush out any problems with them.  The attached kernel patch fixes a couple problems observed in the arm64 kprobes:

- irq needs to be masked during single step
- the address to continue execution should be statically computed and not change

With the attached patch and recent correction to the systemtap runtime time.c for arm64. periodic.stp run on arm64:

# ~/systemtap_write/install/bin/stap --all-modules  periodic.stp 
#monitoring timer periods (press control-c for output)
^C#type   function                                            period(us)     count
kernel  0xfffffdfffcaf2c50 [stap_41b9ddd4f103a617201d73e05       10008      1230
kernel  0xfffffdfffcaf3280 [stap_41b9ddd4f103a617201d73e05       20032       614
process xfsaild/dm-0(404)                                        50000       246
process rcu_sched(7)                                            159873        77
work_q  phy_state_machine                                      1000011        11
work_q  vmstat_update                                          1000009        11
work_q  vmstat_update                                          1000919        11
work_q  vmstat_update                                          1000010        11
work_q  vmstat_update                                          1000018        11
work_q  vmstat_update                                          1352511         8
work_q  vmstat_update                                          1512865         7
kernel  br_hello_timer_expired+0x0/0x90 [bridge]               1999999         5
kernel  dev_watchdog+0x0/0x280 [kernel]                        4999999         2
kernel  0xfffffdfffcaf1b40 [stap_41b9ddd4f103a617201d73e05    10021293         1
kernel  0xfffffdfffcaf1b40 [stap_41b9ddd4f103a617201d73e05    10021056         1
work_q  bdi_writeback_workfn                                   5010523         1
kernel  0xfffffdfffcaf1b40 [stap_41b9ddd4f103a617201d73e05    10021037         1
work_q  xfs_reclaim_worker                                     5010503         1
kernel  0xfffffdfffcaf1b40 [stap_41b9ddd4f103a617201d73e05    10011035         1
work_q  vmstat_update                                          5941334         1
kernel  0xfffffdfffcaf1b40 [stap_41b9ddd4f103a617201d73e05    10022237         1
work_q  vmstat_update                                          5992305         1
kernel  0xfffffdfffcaf1b40 [stap_41b9ddd4f103a617201d73e05    10023836         1
kernel  writeout_period+0x0/0x9c [kernel]                      5992292         1
kernel  0xfffffdfffcaf1b40 [stap_41b9ddd4f103a617201d73e05    10021077         1
kernel  0xfffffdfffcaf1b40 [stap_41b9ddd4f103a617201d73e05    10021999         1

-Will

[-- Attachment #2: kprobes-aarch64-irq2.patch --]
[-- Type: text/x-patch, Size: 3262 bytes --]

diff -up arch/arm64/kernel/kprobes.c.irq arch/arm64/kernel/kprobes.c
--- arch/arm64/kernel/kprobes.c.irq	2014-10-29 22:01:35.234174228 -0400
+++ arch/arm64/kernel/kprobes.c	2014-10-30 16:10:16.165804247 -0400
@@ -23,6 +23,7 @@
 #include <linux/stop_machine.h>
 #include <linux/stringify.h>
 #include <asm/traps.h>
+#include <asm/ptrace.h>
 #include <asm/cacheflush.h>
 #include <asm/debug-monitors.h>
 #include <asm/system_misc.h>
@@ -47,12 +48,23 @@ static void __kprobes arch_prepare_ss_sl
 
 	flush_icache_range((uintptr_t) (p->ainsn.insn),
 			   (uintptr_t) (p->ainsn.insn) + MAX_INSN_SIZE);
+
+	/*
+	 * Needs restoring of return address after stepping xol.
+	 */
+	p->ainsn.restore.addr = (unsigned long) p->addr +
+	  sizeof(kprobe_opcode_t);
+	p->ainsn.restore.type = RESTORE_PC;
 }
 
 static void __kprobes arch_prepare_simulate(struct kprobe *p)
 {
 	if (p->ainsn.prepare)
 		p->ainsn.prepare(p, &p->ainsn);
+
+	/* This instructions is not executed xol. No need to adjust the PC */
+	p->ainsn.restore.addr = 0;
+	p->ainsn.restore.type = NO_RESTORE;
 }
 
 static void __kprobes arch_simulate_insn(struct kprobe *p, struct pt_regs *regs)
@@ -167,9 +179,9 @@ spsr_set_debug_flag(struct pt_regs *regs
 	unsigned long spsr = regs->pstate;
 
 	if (mask)
-		spsr |= (1 << 9);
+		spsr |= PSR_D_BIT;
 	else
-		spsr &= ~(1 << 9);
+		spsr &= ~PSR_D_BIT;
 
 	regs->pstate = spsr;
 }
@@ -186,7 +198,7 @@ static void __kprobes kprobes_save_local
 {
 	struct kprobe_ctlblk *kcb = get_kprobe_ctlblk();
 
-	kcb->saved_irqflag = (interrupts_enabled(regs)) ? 0 : 1;
+	kcb->saved_irqflag = regs->pstate;
 	regs->pstate |= PSR_I_BIT;
 }
 
@@ -194,10 +206,10 @@ static void __kprobes kprobes_restore_lo
 {
 	struct kprobe_ctlblk *kcb = get_kprobe_ctlblk();
 
-	if (kcb->saved_irqflag)
-		regs->pstate &= ~PSR_I_BIT;
-	else
+	if (kcb->saved_irqflag & PSR_I_BIT)
 		regs->pstate |= PSR_I_BIT;
+	else
+		regs->pstate &= ~PSR_I_BIT;
 }
 
 static void __kprobes
@@ -243,19 +255,13 @@ static void __kprobes setup_singlestep(s
 		/* prepare for single stepping */
 		slot = (unsigned long)p->ainsn.insn;
 
-		/*
-		 * Needs restoring of return address after stepping xol.
-		 */
-		p->ainsn.restore.addr = instruction_pointer(regs) +
-				sizeof(kprobe_opcode_t);
-
-		p->ainsn.restore.type = RESTORE_PC;
-
 		set_ss_context(kcb, slot);	/* mark pending ss */
 
 		if (kcb->kprobe_status == KPROBE_REENTER)
 			spsr_set_debug_flag(regs, 0);
 
+		/* IRQs and single stepping do not mix well. */
+		local_irq_disable();
 		kernel_enable_single_step(regs);
 		instruction_pointer(regs) = slot;
 	} else	{
@@ -304,8 +310,7 @@ post_kprobe_handler(struct kprobe_ctlblk
 	/* return addr restore if non-branching insn */
 	if (cur->ainsn.restore.type == RESTORE_PC) {
 		instruction_pointer(regs) = cur->ainsn.restore.addr;
-		cur->ainsn.restore.addr = 0;
-		cur->ainsn.restore.type = NO_RESTORE;
+		if (!instruction_pointer(regs)) BUG();
 	}
 
 	/* restore back original saved kprobe variables and continue */
@@ -343,6 +348,7 @@ int __kprobes kprobe_fault_handler(struc
 		 * normal page fault.
 		 */
 		instruction_pointer(regs) = (unsigned long)cur->addr;
+		if (!instruction_pointer(regs)) BUG();
 		if (kcb->kprobe_status == KPROBE_REENTER)
 			restore_previous_kprobe(kcb);
 		else

Re: arm64 kprobes/systemtap support progress

[William Cohen]

On 11/02/2014 04:02 PM, William Cohen wrote:
> Hi All,
> 
> Dave Long has been working on getting arm64 kprobes support merged into the upstream kernels.  The kprobes64 branch of the git tree at 
> https://git.linaro.org/people/dave.long/linux.git
> 

A bit more poking around with the arm64 kprobe support and found that it does not work well with smp at the moment. There appears to be some issues in linux/arch/arm64/kernel/insn.c and getting the processors to patch in the kprobe breakpoint. After booting the machine in uniprocessor mode (kernel boot parameter maxcpus=1) the kprobes were much more stable. I was able to run the systemtap syscall tests with:

make installcheck RUNTESTFLAGS="--debug systemtap.syscall/*syscall.exp"

There were a lot of failures on arm64 due to a number of the syscalls being remapped.  An incomplete list of the syscall mappings:

open -> openat
chmod -> fchmodat
chown -> fchown
lchown -> fchownat
mkdir -> mkdirat
rmdir -> unlinkat
dup2 -> dup3
inotify_init -> inotify_init1
link -> linkat
readlink -> readlinkat
symlink -> symlinkat


Thus, get the following mediocre results from the syscall tests:


		=== systemtap Summary ===

# of expected passes		110
# of unexpected failures	70
# of untested testcases		2
# of unsupported tests		4


I am getting more adventurous and trying to run more of the systemtap testsuite to see what other things are not right on arm64.

-Will

Re: arm64 kprobes/systemtap support progress

[William Cohen]

On 11/05/2014 12:12 PM, William Cohen wrote:
> On 11/02/2014 04:02 PM, William Cohen wrote:
>> Hi All,
>>
>> Dave Long has been working on getting arm64 kprobes support merged into the upstream kernels.  The kprobes64 branch of the git tree at 
>> https://git.linaro.org/people/dave.long/linux.git
>>
> 
> A bit more poking around with the arm64 kprobe support and found that it does not work well with smp at the moment. There appears to be some issues in linux/arch/arm64/kernel/insn.c and getting the processors to patch in the kprobe breakpoint. After booting the machine in uniprocessor mode (kernel boot parameter maxcpus=1) the kprobes were much more stable. I was able to run the systemtap syscall tests with:
> 
> make installcheck RUNTESTFLAGS="--debug systemtap.syscall/*syscall.exp"
> 
> There were a lot of failures on arm64 due to a number of the syscalls being remapped.  An incomplete list of the syscall mappings:
> 
> open -> openat
> chmod -> fchmodat
> chown -> fchown
> lchown -> fchownat
> mkdir -> mkdirat
> rmdir -> unlinkat
> dup2 -> dup3
> inotify_init -> inotify_init1
> link -> linkat
> readlink -> readlinkat
> symlink -> symlinkat
> 
> 
> Thus, get the following mediocre results from the syscall tests:
> 
> 
> 		=== systemtap Summary ===
> 
> # of expected passes		110
> # of unexpected failures	70
> # of untested testcases		2
> # of unsupported tests		4
> 
> 
> I am getting more adventurous and trying to run more of the systemtap testsuite to see what other things are not right on arm64.
> 
> -Will
> 


Hi All,

There have been some additional fixes for the arm64 kprobes support in the kernel.  The cause of the smp hanging in the instruction patch code has been identified and a patch has been accepted upstream to fix this.  In most cases kprobes on arm64 uses single stepping to execute out of line code, but there are some instructions that need to be simulated.  As more of the systemtap tests are run some errors have been found and fixed in the kprobes instruction simulation code.  Dave Long is reviewing the instruction simulation code to eliminate other remaining errors in the instruction simulation code. Right now the following systemtap example in the testsuite appears to trigger one of those simulator errors:

stap -w functioncallcount.stp "*@mm/*.c" -c "sleep 1"

Dave Smith patched the testsuite/systemtap.syscall tests to allow the syscall tests to recognize openat syscalls for the open syscall which improves the syscall testresults to:
		=== systemtap Summary ===

# of expected passes		132
# of unexpected failures	50
# of untested testcases		2
# of unsupported tests		4



-Will

Re: arm64 kprobes/systemtap support progress

[William Cohen]

After making some additional fixes in the arm64 kprobes support for simulating instructions that are not single stepped the systemtap testsuite made a complete run without crashing the arm64 system.

		=== systemtap Summary ===

# of expected passes		2736
# of unexpected failures	689
# of unexpected successes	1
# of expected failures		312
# of unknown successes		2
# of known failures		59
# of untested testcases		408
# of unsupported tests		17

The test results have been uploaded to:

web.elastic.org/~dejazilla/viewsummary.php?summary=%3D%27%3C5464A1C7.7090000%40redhat.com%3E%27

I have not had a chance to review the test results yet.  I am sure there is room for improvement in them.  There are some syscall tests that need to be updated for the syscalls that the arm64 used and some of the tests fail because currently there is no uprobes support.

-Will

Re: arm64 kprobes/systemtap support progress

[David Smith]

On 11/13/2014 06:27 AM, William Cohen wrote:
> I have not had a chance to review the test results yet.  I am sure there
> is room for improvement in them.  There are some syscall tests that need
> to be updated for the syscalls that the arm64 used and some of the tests
> fail because currently there is no uprobes support.

Hmm, a test failing for no uprobes support shouldn't happen. Any test
that uses uprobes should have be running the 'uprobes_p' function and
exiting before the test is run if the platform doesn't have uprobes. The
test should get marked as untested.

-- 
David Smith
dsmith@redhat.com
Red Hat
http://www.redhat.com
256.217.0141 (direct)
256.837.0057 (fax)

Re: arm64 kprobes/systemtap support progress

[William Cohen]

After some some minor fixes (pr17622) the arm64 systemtap test results
are looking much better now:

		=== systemtap Summary ===

# of expected passes		3475
# of unexpected failures	112
# of unexpected successes	1
# of expected failures		312
# of unknown successes		2
# of known failures		59
# of untested testcases		408
# of unsupported tests		17
runtest completed at Wed Nov 19 12:59:55 2014

The summary has been upleaded to dejazilla: 

https://web.elastic.org/~dejazilla/viewsummary.php?summary=%3D%27%3C546CDB29.5020709%40redhat.com%3E%27

I did a quick look over of the current results and categorized most of
them below.

The following tests are failing because systemtap not recognizing the name in the SDT_V3 output:

FAIL: singleparam (3)
FAIL: return (0)
FAIL: multiparams (0)
FAIL: stacktrace (0)
FAIL: ./systemtap.base/sdt_varname.stp sdt_varname libsdt_varname.so -c ./sdt_varname


Unable to find target variable:

FAIL: at_var_tracepoint compilation
FAIL: at_var_void_stmt (0, 2)
FAIL: global_var_kernel compilation
FAIL: ./systemtap.examples/network/netdev build
FAIL: ./systemtap.examples/network/tcp_trace build
FAIL: buildok/networking-detailed.stp
FAIL: buildok/nfs-detailed.stp
FAIL: buildok/nfsd-detailed.stp
FAIL: buildok/nfsd-embedded.stp
FAIL: buildok/seventeen.stp
FAIL: buildok/tty-detailed.stp
FAIL: buildok/xtime.stp
FAIL: semok/seventeen.stp
FAIL: semok/thirtynine.stp
FAIL: semok/thirtysix.stp

Unable to find a probe point:

FAIL: debugpath-good (eof)
FAIL: warnings (0)
FAIL: ./systemtap.examples/process/procmod_watcher build
FAIL: buildok/nfs-all-probes.stp
FAIL: buildok/nfs_proc-detailed.stp
FAIL: buildok/vfs-all-probes.stp
FAIL: buildok/vfs-detailed.stp
FAIL: semok/doubleglob.stp

Uprobes support not available:

FAIL: bad-code
FAIL: callee (simple - probing .callee(foo))
FAIL: callee (multicalls - probing main .callees)
FAIL: callee (inlined - probing main .callees)
FAIL: callee (extern - probing main .callees)
FAIL: callee (reloc - probing shlib foo .callees)
FAIL: pr16719 (user - can't start stap)
FAIL: sdt_misc wildcard (0) V1_uprobe
FAIL: sdt_misc wildcard (0) V2_uprobe
FAIL: sdt_misc wildcard (0) V3_uprobe
FAIL: stmt_inlines (probing error, expected 4, got 0)
FAIL: stmt_rel (bio_init sanity check)
FAIL: 64_BIT_UTRACE_SYSCALL_ARGS shutdown (eof)
FAIL: ./systemtap.examples/general/py2example build
FAIL: ./systemtap.examples/memory/last_100_frees build

backtracing not working properly:

FAIL: caller shutdown (eof)
FAIL: early test shutdown (m2 eof)
FAIL: backtrace of yyy_func2 (0)
FAIL: print_syms of yyy_func2 (2)
FAIL: backtrace of yyy_func3 (0)
FAIL: print_syms of yyy_func3 (0)
FAIL: backtrace of yyy_func4 (0)
FAIL: print_syms of yyy_func4 (0)
FAIL: print_syms didn't find systemtap_test_module1 (0)
FAIL: print_syms didn't find [kernel] (0)
FAIL: backtrace.stp didn't call exit (0)

time issue:

FAIL: gtod (100ms interval) (19)

plt support not impletement:

FAIL: listing_mode (untested probe type: process(number).plt)
FAIL: listing_mode (untested probe type: process(number).plt.return)
FAIL: listing_mode (untested probe type: process(number).plt(string))
FAIL: listing_mode (untested probe type: process(number).plt(string).return)

problem with register access (sp (reg 31) not part of pt_reg array):

FAIL: rlimit unlimited
FAIL: rlimit AS increase (as root)
FAIL: rlimit AS realistic
FAIL: rlimit CPU increase (as root)
FAIL: rlimit CPU realistic
FAIL: rlimit NPROC increase (as root)
FAIL: rlimit NPROC realistic
FAIL: rlimit STACK increase (as root)
FAIL: rlimit STACK realistic
FAIL: rlimit FSIZE increase (as root)
FAIL: rlimit FSIZE realistic

Funky kernel name (has '+'):
FAIL: Valid Server Client Arguments: --client-options -r UNAME
FAIL: Valid Server Client Arguments: --client-options -a i386 -D X=Y -I foo -m test -r UNAME


depricated syscalls removed on arm64:

28 nd_syscall and syscall tests failed most of these appear to be
because of the depreciated syscalls not being implemented on arm64

-Will

Re: arm64 kprobes/systemtap support progress

[David Smith]

On 11/20/2014 10:14 AM, William Cohen wrote:
> I did a quick look over of the current results and categorized most of
> them below.

... stuff deleted ...

> Uprobes support not available:
> 
> FAIL: bad-code

The above doesn't need uprobes, but it does to a user backtrace. (Or
does a user backtrace require uprobes?)

> FAIL: callee (simple - probing .callee(foo))
> FAIL: callee (multicalls - probing main .callees)
> FAIL: callee (inlined - probing main .callees)
> FAIL: callee (extern - probing main .callees)
> FAIL: callee (reloc - probing shlib foo .callees)
> FAIL: pr16719 (user - can't start stap)
> FAIL: sdt_misc wildcard (0) V1_uprobe
> FAIL: sdt_misc wildcard (0) V2_uprobe
> FAIL: sdt_misc wildcard (0) V3_uprobe
> FAIL: stmt_inlines (probing error, expected 4, got 0)
> FAIL: stmt_rel (bio_init sanity check)
> FAIL: ./systemtap.examples/general/py2example build
> FAIL: ./systemtap.examples/memory/last_100_frees build

I fixed all the above by adding 'uprobes_p' checks to the test cases.

> FAIL: 64_BIT_UTRACE_SYSCALL_ARGS shutdown (eof)

The above one isn't a uprobes problem. That test only uses utrace, not
uprobes (it passes on ia64 for instance, which has utrace but not uprobes).

> plt support not impletement:
>
> FAIL: listing_mode (untested probe type: process(number).plt)
> FAIL: listing_mode (untested probe type: process(number).plt.return)
> FAIL: listing_mode (untested probe type: process(number).plt(string))
> FAIL: listing_mode (untested probe type: process(number).plt(string).return)

I've fixed these, you should get KFAILs now.

-- 
David Smith
dsmith@redhat.com
Red Hat
http://www.redhat.com
256.217.0141 (direct)
256.837.0057 (fax)

Re: arm64 kprobes/systemtap support progress

[William Cohen]

On 11/20/2014 05:56 PM, David Smith wrote:
> On 11/20/2014 10:14 AM, William Cohen wrote:
>> I did a quick look over of the current results and categorized most of
>> them below.
> 
> ... stuff deleted ...
> 
>> Uprobes support not available:
>>
>> FAIL: bad-code
> 
> The above doesn't need uprobes, but it does to a user backtrace. (Or
> does a user backtrace require uprobes?)

Hi David,

For the bad-code it doesn't seem to use the uproces, but it gave message about user-space process-tracking facilities not being available:

Running ./systemtap.base/bad-code.exp ...
Executing on host: gcc ./systemtap.base/bad-code.c  -g  -lm   -o bad-code    (timeout = 300)
spawn -ignore SIGHUP gcc ./systemtap.base/bad-code.c -g -lm -o bad-code

PASS: bad-code.c compile
Running: stap ./systemtap.base/bad-code.stp -w -d ./bad-code -c ./bad-code
spawn stap ./systemtap.base/bad-code.stp -w -d ./bad-code -c ./bad-code

user-space process-tracking facilities not available [man error::process-tracking]

Pass 4: compilation failed.  [man error::pass4]

Executing: kill -INT -4863
main: 0, func: 0, libc: 0
FAIL: bad-code

Thanks for adding the fixes for the ones below.  I also added some fixes to address the syscall remappings for the syscall tests.  It looks like the failures might be less than 100 now.

-Will


> 
>> FAIL: callee (simple - probing .callee(foo))
>> FAIL: callee (multicalls - probing main .callees)
>> FAIL: callee (inlined - probing main .callees)
>> FAIL: callee (extern - probing main .callees)
>> FAIL: callee (reloc - probing shlib foo .callees)
>> FAIL: pr16719 (user - can't start stap)
>> FAIL: sdt_misc wildcard (0) V1_uprobe
>> FAIL: sdt_misc wildcard (0) V2_uprobe
>> FAIL: sdt_misc wildcard (0) V3_uprobe
>> FAIL: stmt_inlines (probing error, expected 4, got 0)
>> FAIL: stmt_rel (bio_init sanity check)
>> FAIL: ./systemtap.examples/general/py2example build
>> FAIL: ./systemtap.examples/memory/last_100_frees build
> 
> I fixed all the above by adding 'uprobes_p' checks to the test cases.
> 
>> FAIL: 64_BIT_UTRACE_SYSCALL_ARGS shutdown (eof)
> 
> The above one isn't a uprobes problem. That test only uses utrace, not
> uprobes (it passes on ia64 for instance, which has utrace but not uprobes).
> 
>> plt support not impletement:
>>
>> FAIL: listing_mode (untested probe type: process(number).plt)
>> FAIL: listing_mode (untested probe type: process(number).plt.return)
>> FAIL: listing_mode (untested probe type: process(number).plt(string))
>> FAIL: listing_mode (untested probe type: process(number).plt(string).return)
> 
> I've fixed these, you should get KFAILs now.
> 

Re: arm64 kprobes/systemtap support progress

[David Long]

On 11/20/14 22:49, William Cohen wrote:
> On 11/20/2014 05:56 PM, David Smith wrote:
>> On 11/20/2014 10:14 AM, William Cohen wrote:
>>> I did a quick look over of the current results and categorized most of
>>> them below.
>>
>> ... stuff deleted ...
>>
>>> Uprobes support not available:
>>>
>>> FAIL: bad-code
>>
>> The above doesn't need uprobes, but it does to a user backtrace. (Or
>> does a user backtrace require uprobes?)
>
> Hi David,
>
> For the bad-code it doesn't seem to use the uproces, but it gave message about user-space process-tracking facilities not being available:
>
> Running ./systemtap.base/bad-code.exp ...
> Executing on host: gcc ./systemtap.base/bad-code.c  -g  -lm   -o bad-code    (timeout = 300)
> spawn -ignore SIGHUP gcc ./systemtap.base/bad-code.c -g -lm -o bad-code
>
> PASS: bad-code.c compile
> Running: stap ./systemtap.base/bad-code.stp -w -d ./bad-code -c ./bad-code
> spawn stap ./systemtap.base/bad-code.stp -w -d ./bad-code -c ./bad-code
>
> user-space process-tracking facilities not available [man error::process-tracking]
>
> Pass 4: compilation failed.  [man error::pass4]
>
> Executing: kill -INT -4863
> main: 0, func: 0, libc: 0
> FAIL: bad-code
>
> Thanks for adding the fixes for the ones below.  I also added some fixes to address the syscall remappings for the syscall tests.  It looks like the failures might be less than 100 now.
>
> -Will

This is pretty good news.  Thanks for putting in so much effort.

-dl

Re: arm64 kprobes/systemtap support progress

[William Cohen]

On 11/21/2014 01:21 AM, David Long wrote:
> On 11/20/14 22:49, William Cohen wrote:
>> On 11/20/2014 05:56 PM, David Smith wrote:
>>> On 11/20/2014 10:14 AM, William Cohen wrote:
>>>> I did a quick look over of the current results and categorized most of
>>>> them below.
>>>
>>> ... stuff deleted ...
>>>
>>>> Uprobes support not available:
>>>>
>>>> FAIL: bad-code
>>>
>>> The above doesn't need uprobes, but it does to a user backtrace. (Or
>>> does a user backtrace require uprobes?)
>>
>> Hi David,
>>
>> For the bad-code it doesn't seem to use the uproces, but it gave message about user-space process-tracking facilities not being available:
>>
>> Running ./systemtap.base/bad-code.exp ...
>> Executing on host: gcc ./systemtap.base/bad-code.c  -g  -lm   -o bad-code    (timeout = 300)
>> spawn -ignore SIGHUP gcc ./systemtap.base/bad-code.c -g -lm -o bad-code
>>
>> PASS: bad-code.c compile
>> Running: stap ./systemtap.base/bad-code.stp -w -d ./bad-code -c ./bad-code
>> spawn stap ./systemtap.base/bad-code.stp -w -d ./bad-code -c ./bad-code
>>
>> user-space process-tracking facilities not available [man error::process-tracking]
>>
>> Pass 4: compilation failed.  [man error::pass4]
>>
>> Executing: kill -INT -4863
>> main: 0, func: 0, libc: 0
>> FAIL: bad-code
>>
>> Thanks for adding the fixes for the ones below.  I also added some fixes to address the syscall remappings for the syscall tests.  It looks like the failures might be less than 100 now.
>>
>> -Will
> 
> This is pretty good news.  Thanks for putting in so much effort.
> 
> -dl
> 
> 

Hi Dave and David,

The test results are now down to 83 failures:

https://web.elastic.org/~dejazilla/viewsummary.php?summary=%3D%27%3C546F297B.7010900%40redhat.com%3E%27

-Will