From: William Cohen <wcohen@redhat.com>
To: David Smith <dsmith@redhat.com>
Cc: systemtap@sourceware.org
Subject: Re: Recent review of SystemTap test results on ARM running Fedora 15 hard float.
Date: Fri, 24 Feb 2012 18:27:00 -0000 [thread overview]
Message-ID: <4F47D662.9000509@redhat.com> (raw)
In-Reply-To: <4F47B4E4.2080803@redhat.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
next prev parent reply other threads:[~2012-02-24 18:27 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-02-23 19:06 William Cohen
2012-02-23 20:55 ` David Smith
2012-02-23 22:06 ` William Cohen
2012-02-23 22:56 ` David Smith
2012-02-24 16:04 ` David Smith
2012-02-24 18:27 ` William Cohen [this message]
2012-02-24 19:28 ` David Smith
2012-02-24 21:49 ` William Cohen
2012-02-25 19:40 ` Mark Wielaard
2012-02-27 15:33 ` William Cohen
2012-02-27 16:10 ` Mark Wielaard
2012-02-27 21:54 ` Mark Wielaard
2012-02-27 22:20 ` William Cohen
2012-02-23 22:12 ` David Smith
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=4F47D662.9000509@redhat.com \
--to=wcohen@redhat.com \
--cc=dsmith@redhat.com \
--cc=systemtap@sourceware.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).