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 02:27 PM, David Smith wrote:
> 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.



It should be doing this code in kernel-space. Printed valude of user_mode() to verify.  Ruled out #1. It is getting information from _stp_current_pt_regs().

I started taking a look at the uaddr() and umodname() code to see where they are getting things.
See where REG_IP() coming from for arm, runtime/regs.h:

#elif defined (__arm__)

#define REG_IP(regs) regs->ARM_pc
#define REG_SP(regs) regs->ARM_sp
#define REG_LINK(regs) regs->ARM_lr

See ARM_pc defined in:

http://lxr.linux.no/#linux+v3.2.7/arch/arm/include/asm/ptrace.h#L114

I will do some more looking around why this doesn't work this evening.

-Will