Re: running testcases with unoptimized translation

[Li Guanglei <guanglei at cn dot ibm dot com>]

David Smith wrote:
> On Wed, 2006-08-09 at 11:54 +0800, Li Guanglei wrote:
>
> Hmm, testsuite/buildok/sched_test.stp has never worked for me, optimized
> or unoptimized.

It can pass the test for me on a 4-way ppc64 box. You box isn't a SMP, 
right? I'll verify it on my pc tomorrow.

> When I run the testsuite unoptimized (by hard-coding the unoptimize flag
> on), I get the following extra failures:
>
> (1) FAIL: ./testsuite/semok/optimize.stp
>
> This one makes sense, because it is written to fail if unoptimized.
>
> (2) FAIL: ./testsuite/buildok/syscall.stp
>
> This one points out a bug in syscalls.stp in the syscall.kexec_load
> probe.  It looks like this:
>
> 	segments_uaddr = $segments_uaddr
>
> Should be this:
>
> 	segments_uaddr = $segments
>
> I'll fix that one.
>
> (3) FAIL: ./testsuite/buildok/twentyfour.stp
>
> This one also makes sense, because it is written to fail if unoptimized.

I got some errors with ./testsuite/buildok/syscall.stp:

Pass 1: parsed user script and 41 library script(s) in 
320usr/0sys/383real ms.
semantic error: unresolved target-symbol expression: identifier '$len' 
at /usr/local/share/systemtap/tapset/syscalls2.stp:912:39
semantic error: unresolved target-symbol expression: identifier '$len' 
at /usr/local/share/systemtap/tapset/ppc64/syscalls.stp:182:8
semantic error: unresolved target-symbol expression: identifier 
'$error_code' at /usr/local/share/systemtap/tapset/syscalls.stp:501:18
semantic error: unresolved target-symbol expression: identifier '$fd' 
at /usr/local/share/systemtap/tapset/syscalls.stp:782:29
semantic error: unresolved target-symbol expression: identifier 
'$offset' at /usr/local/share/systemtap/tapset/syscalls.stp:1943:11

I took a look at the dwarf info of sys_sched_setaffinity which 
complains of unresolved $len. The dwarf says address rang in the loc 
list of $len is 0xc0000000000469a0..0xc0000000000469a4, and stap -vv 
says that stap put the probe point at 0xc0000000000469a4. But actually 
0xc0000000000469a4 marks the first address past the end of the address 
range over which the location is valid. So stap puts this kprobe at 
the wrong address.

I searched the bugzilla and found there is an old bugzilla entry 2438 
which should states the same problem. Alexandre has fixed this GCC bug 
but we have to wait before it's available on gcc update version.

- Guanglei