public inbox for systemtap@sourceware.org
 help / color / mirror / Atom feed
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

  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).