Re: [Bug testsuite/11514] nd_syscall.exp takes more than 10 times longer than syscall.exp testcase

[Mark Wielaard <mjw at redhat dot com>]

On Thu, 2010-04-22 at 09:15 +0530, Ananth N Mavinakayanahalli wrote:
> On Wed, Apr 21, 2010 at 07:05:39PM -0000, jistone at redhat dot com wrote:
> > 
> > But on PPC64, it's a little more complicated to deal with function descriptors.
> >  In some cases the returned address is actually a pointer to the real address,
> > and in other cases it tries to search again with a '.' added to the name.  We
> > need to deal with this too if we're bypassing kprobe_lookup_name().
> 
> Right, on PPC64, the symbol table address entry foo, for a function foo()
> is a data address while .foo is the actual text address. In the past,
> the System.map would contain both foo and .foo; RHEL5 on, the .foo
> entries have been omitted from there.
>
> If possible, I'd suggest that you don't bypass kprobe_lookup_name() for
> debuginfoless probes, since it handles more cases like symbol clashes
> between modules and such; let the kernel resolve the addresses for us.

The optimization uses the kernel to resolve the addresses for us, but
through kallsyms_on_each_symbol() instead of
kprobe_lookup_name/kallsyms_lookup_name(). Since it does indeed seem
that doesn't do anything special for PPC64 function descriptors I have
disabled the optimization on PPC64 for now (commit 2cbd95). But you
might want to double check that kallsyms_on_each_symbol() works as
expected on PPC64 anyway, since it really is a lot more efficient when
having to lookup multiple (possible non-existing) symbol names. The
optimization was added because kallsyms_lookup_name() needs to
uncompress the kernel symbol table on each pass.

If it can be made to work on every architecture we might want to push a
similar optimization upstream to make register_kprobes() do the same. We
are currently not using register_kprobes() because a) it is as slow as
looping over register_kprobe() ourselves, and b) because we allow
registration failures if the probe is "optional". But both could be
added to the upstream interface if needed, and that would then benefit
any consumer that tries to register lots of kprobes by symbol name.

Cheers,

Mark