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

[David Smith <dsmith@redhat.com>]

On 02/24/2012 12:26 PM, William Cohen wrote:

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


...

Interesting.  So we got an address, but not a good address.  Here's the
source of uaddr():

function uaddr:long()
%{ /* pure */ /* myproc-unprivileged */
  struct pt_regs *uregs;


  if (CONTEXT->probe_flags & _STP_PROBE_STATE_USER_MODE)
    uregs = CONTEXT->uregs;
  else
    uregs = _stp_current_pt_regs();

  if (uregs)
    THIS->__retvalue = (int64_t) REG_IP(uregs);
  else
    THIS->__retvalue = 0;
%}

There are basically 3 possibilities of error here:

1) We're getting a bad uregs pointer from the context structure
2) We're getting a bad uregs pointer from the _stp_current_pt_regs().
3) REG_IP() isn't interpreting the good uregs pointer correctly

If you want to track this down further, first try to figure out where
we're getting uregs from.


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


prelink being available on ARM in the future shouldn't be a problem.
That commit does a file existence check on prelink, not an arch check.
So if prelink shows up it will get used.

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