Re: dwarfless failures on ppc64

[Jim Keniston <jkenisto at us dot ibm dot com>]

On Tue, 2008-05-20 at 15:58 -0700, Roland McGrath wrote:
> > The problem with 'W' entries in nm listings is that some of them refer
> > to "real" functions and some don't.  
> 
...
> 
> What is true is that there may be many symbols that are all aliases for
> the same actual address.  Some of those symbols might be weak and others
> not (also some might be local).  In the kernel there is one case where
> this is commonly true, that is many weak symbols are aliases for
> sys_ni_syscall (which is a stub function that returns (long)-ENOSYS).

Yes, that's exactly what I'm seeing on my system.  The weak syscall
symbols are created via the cond_syscall macro.

> 
> I don't have a clear sense from what you've said of exactly how
> systemtap is behaving.  If you probe sys_* for example, that will
> include multiple names that resolve to the same address as
> sys_ni_syscall, and so is requesting several different probes at one
> address.

Without --kelf or --kmap, stap consults only the dwarf.  Since
cond_syscall doesn't yield any dwarf, the "functions" defined thereby
don't get considered by stap.

With --kelf, the weak syscall symbols look like any other text symbols
-- we don't check STB_WEAK -- so they get considered.  This isn't good
in cases like

probe syscall.foo = kernel.function("sys_foo_weak") ?
		kernel.function("compat_sys_foo") { ... }

if sys_foo_weak is an alias for sys_ni_syscall and compat_sys_foo
actually implements the system call.

With --kmap, we currently ignore ALL weak symbols.  This is plainly
wrong, in light of the various weak symbols that correspond to non-stub
functions.

I think the following fix should provide the desired behavior, at least
wrt syscalls: For --kelf or --kmap, consider all weak symbols except
those with the same value as sys_ni_syscall.

Comments/corrections welcome.

> 
> 
> Thanks,
> Roland

Thanks very much.
Jim