Re: Recent review of SystemTap test results on ARM running Fedora 15 hard float.

[William Cohen <wcohen at redhat dot com>]

On 02/24/2012 11:03 AM, David Smith wrote:
> On 02/23/2012 04:55 PM, David Smith wrote:
> 
>> On 02/23/2012 04:06 PM, William Cohen wrote:
>>
>>> On 02/23/2012 03:54 PM, David Smith wrote:
>>>> On 02/23/2012 01:06 PM, William Cohen wrote:
>>>
>>> Hi David,
>>>
>>> Thanks for the comments/questions.
>>>
>>>>
>>>>> I reviewed the SystemTap testsuite failures for Fedora 15 hard float running on ARM.  You can see the recent ARM test results in dejazilla at:
>>>>>
>>>>> http://web.elastic.org/~dejazilla/viewsummary.php?_offset=0&_limit=40&_sort=1A&summary=&age=&rg=&tool=&variant=%3D%27armv7l-unknown-linux-gnu%27&versions=&pass=&fail=&kpass=&kfail=&xpass=&xfail=&untested=&unresolved=&unsupported=&warning=&error=
>>>>
>>>>
> 
> 
>>>>> FAIL: vma_vdsodefault
>>>>>       vma_vdso.stp uses uaddr() which didn't work on arm.
>>>>
>>>>
>>>> Hmm, can you tell in systemtap.log what part of 'uaddr()' didn't work?
>>>
>>> The log wasn't too helpful. When running the test by hand.  Looks like umodename(uaddrr()) == "<unknown>", so getting from
>>>
>>> 	  printf("%s@%x unknown\n", name, uaddr());
>>
>>
>> Hmm, I'll try looking at this one some more.
> 
> 
> The first thing we need to do here is figure out which is really
> failing, uaddr() or umodname().  Could you change the test to just print
> out the return value of uaddr() to see what it is returning?

Added the following to the vma_vdso.stp just inside the (target() == pid())

+      printf("%s umodname(uaddr()) = umodname(%x) = %s\n",
+         name, uaddr(), umodname(uaddr()));


$ ../install/bin/stap  ../systemtap/testsuite/systemtap.base/vma_vdso.stp -c testsuite/vma_vdsodefault.exe 
clock_gettime umodname(uaddr()) = umodname(401096ec) = <unknown>
clock_gettime@401096ec unknown
getuid umodname(uaddr()) = umodname(40254e10) = <unknown>
getuid@40254e10 unknown
getuid umodname(uaddr()) = umodname(40221f5c) = <unknown>
getuid@40221f5c unknown

Below is the maps for the process to see where those addresses would map.  The results of uaddr() do not look correct.


$ more /proc/8622/maps
00008000-00009000 r-xp 00000000 08:10 3540441    /media/greatplains/wcohen/syste
mtap_write/obj/testsuite/vma_vdsodefault.exe
00010000-00011000 rw-p 00000000 08:10 3540441    /media/greatplains/wcohen/syste
mtap_write/obj/testsuite/vma_vdsodefault.exe
40000000-4001d000 r-xp 00000000 08:01 1815738    /lib/ld-2.14.1.so
4001d000-40020000 rw-p 00000000 00:00 0 
40024000-40025000 r--p 0001c000 08:01 1815738    /lib/ld-2.14.1.so
40025000-40026000 rw-p 0001d000 08:01 1815738    /lib/ld-2.14.1.so
40032000-40038000 r-xp 00000000 08:01 1815726    /lib/librt-2.14.1.so
40038000-4003f000 ---p 00006000 08:01 1815726    /lib/librt-2.14.1.so
4003f000-40040000 r--p 00005000 08:01 1815726    /lib/librt-2.14.1.so
40040000-40041000 rw-p 00006000 08:01 1815726    /lib/librt-2.14.1.so
40041000-400ac000 r-xp 00000000 08:01 1815692    /lib/libm-2.14.1.so
400ac000-400b3000 ---p 0006b000 08:01 1815692    /lib/libm-2.14.1.so
400b3000-400b4000 r--p 0006a000 08:01 1815692    /lib/libm-2.14.1.so
400b4000-400b5000 rw-p 0006b000 08:01 1815692    /lib/libm-2.14.1.so
400b5000-401e3000 r-xp 00000000 08:01 1815601    /lib/libc-2.14.1.so
401e3000-401ea000 ---p 0012e000 08:01 1815601    /lib/libc-2.14.1.so
401ea000-401ec000 r--p 0012d000 08:01 1815601    /lib/libc-2.14.1.so
401ec000-401ed000 rw-p 0012f000 08:01 1815601    /lib/libc-2.14.1.so
401ed000-401f0000 rw-p 00000000 00:00 0 
401f0000-401fa000 r-xp 00000000 08:01 1815713    /lib/libgcc_s-4.6.1-20110908.so
.1
401fa000-40201000 ---p 0000a000 08:01 1815713    /lib/libgcc_s-4.6.1-20110908.so
.1
40201000-40202000 rw-p 00009000 08:01 1815713    /lib/libgcc_s-4.6.1-20110908.so
.1
40202000-40216000 r-xp 00000000 08:01 1815734    /lib/libpthread-2.14.1.so
40216000-4021d000 ---p 00014000 08:01 1815734    /lib/libpthread-2.14.1.so
4021d000-4021e000 r--p 00013000 08:01 1815734    /lib/libpthread-2.14.1.so
4021e000-4021f000 rw-p 00014000 08:01 1815734    /lib/libpthread-2.14.1.so
4021f000-40221000 rw-p 00000000 00:00 0 
befdf000-bf000000 rw-p 00000000 00:00 0          [stack]
ffff0000-ffff1000 r-xp 00000000 00:00 0          [vectors]



> 
>>>>> FAIL: uprobeslibgcc-O3default-prelink-debug prelink ./libuprobeslibgcc-O3default-prelink-debug.so
>>>>> FAIL: uprobeslibgcc-O3default-prelink-sep-debug prelink ./libuprobeslibgcc-O3default-prelink-sep-debug.so
>>>>> FAIL: uprobeslibgcc-O3default-prelink-sep-debug-after prelink ./libuprobeslibgcc-O3default-prelink-sep-debug-after.so
>>>>>       uprobes not available on arm

...

> 
> Commit 164901b changes exelib.exp to only run the prelink tests if
> prelink exists on the system.  Try the test again and see if it works
> better.
> 

Prelink isn't currently on the ARM fedora. It might be there in the future.  Commit 164901b eliminates those failures on the ARM.

-Will