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 Mon, 2012-02-27 at 10:33 -0500, William Cohen wrote:
> On 02/25/2012 02:39 PM, Mark Wielaard wrote:
> 
> > 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
> > 
> Does this this test need the uprobes support for this test to work?

Maybe... I am a little fuzzy on the details of when/how vma tracking is
triggered. Technically vma tracking doesn't need uprobes. But it might
be that vma tracking is only enabled/started if uprobes are active. You
might have to look with -DDEBUG_TASK_FINDER_VMA to see what is
happening.

> Below is the output for 2.6.42.3-2.fc15.armv7hl.tegra kernel which doesn't have uprobes support:
> 
> $ stap -e 'probe syscall.clock_gettime, syscall.getuid 
>       { if (pid() == target()) printf("%s 0x%x in %s\n", name, uaddr(),
>                                        umodname(uaddr())) }' -c testsuite/vma_vdsodefault.exe
> clock_gettime 0x4010d6ec in <unknown>
> getuid 0x40258e10 in <unknown>
> getuid 0x40225f5c in <unknown>

It is surprising none of these addresses map to a known vma map name. I
would expect at least some of them to come through libc and/or the
executable itself. You might want to extend the test scope to some other
(all?) syscalls and see which user address called into the kernel and
which umodname that corresponds to.

And maybe turn on -DDEBUG_TASK_FINDER_VMA to see which address ranges
are known to the stap runtime.

Cheers,

Mark


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