This is the mail archive of the systemtap@sourceware.org mailing list for the systemtap project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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


On Fri, Feb 24, 2012 at 01:27:43PM -0600, David Smith wrote:
> On 02/24/2012 12:26 PM, William Cohen wrote:
> >>>>>> 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.

Note that this test explicitly tries to test an address has an known
module name, even if it is in the vdso, which is normally randomly
allocated in the process address space.

In the vma_vdso.c test program we see it uses a trick to make sure
we end up in the vdso (this depends on the implementation of clock_gettime
on the platform, so make sure on ARM this also results into actually
going into the vdso).

  /* Give an invalid clockid_t on purpose so the vdso has to call
     through to the kernel syscall. */

The testcase also tests the testuid call in two different ways.
Maye that is an easier case on ARM?

Then in vma_vdso.stp we see that the probes are in kernel space:
probe syscall.clock_gettime, syscall.getuid

It would surprise me if the uaddr() was really wrong, but it could
be. I suspect that the uaddr() is in the vdso and the vdso tracker
is broken on ARM.

A simpler test would be running this:

stap -e 'probe syscall.clock_gettime, syscall.getuidr
         { if (pid() == target()) printf("%s 0x%x in %s\n", name, uaddr(),
                                         umodname(uaddr())) }' \
     -c testsuite/vma_vdso-m64.exe

Which on x86_64 gives:

clock_gettime 0x7fff689ff9cf in vdso
getuid 0x3c5c0ed819 in /usr/lib64/libc-2.15.so
getuid 0x3c5c0bb007 in /usr/lib64/libc-2.15.so

Does that fail for all invocations on ARM?

If it is the vdso tracker then you want to take a look at
runtime/vma.c _stp_vma_match_vdso will give some debug output
with stap -DDEBUG_TASK_FINDER_VMA

Cheers,

Mark


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]