Re: manual SyS_foo management is unnecessary?

[Josh Stone <jistone at redhat dot com>]

On 06/14/2010 02:32 PM, David Smith wrote:
> Interesting.  I hadn't realized pr10327 applied to kernel space as well
> as user space (since all the examples in pr10327 only applied to user
> space).

Right - the malloc example is a case where people are likely to care,
since glibc uses an internal name for the real thing, but this should
work with any ELF aliasing.


>> With alias-resolution in place, that "SyS_open!,sys_open" bit is
>> unnecessary, but harmless.  There are worse cases though:
>>
>>   probe syscall.sendfile = kernel.function("SyS_sendfile").call ?,
>>                            kernel.function("sys_sendfile").call ?,
>>                            kernel.function("SyS_sendfile64").call ?,
>>                            kernel.function("sys_sendfile64").call ?
>>
>> Since this doesn't have !-sufficiency, and we resolve the sys_sendfile
>> alias too, we end up with duplicate probes.  We'd have to be a bit more
>> clever with some private tapset names to get around this.
>>
>> (Note: we do detect duplicate addresses for wildcard matching, but that
>> doesn't come into play with distinct probe specifications as above.  We
>> can't really know if the duplication was intended.)
> 
> Why does the above example need private tapset names?  Couldn't it just be:
> 
> probe syscall.sendfile = kernel.function("sys_sendfile").call ?,
>                          kernel.function("sys_sendfile64").call ?

That's what I'm proposing to change it to, yes.  The private tapset name
would only be needed if we were to keep the SyS names in place and start
using "!" too.  I'd rather just remove all the SyS stuff.

> On s390x anyway, those 2 functions don't appear to be aliases of each other:
> 
> # stap -l 'kernel.function("sys_sendfile")'
> kernel.function("SyS_sendfile@fs/read_write.c:880")
> # stap -l 'kernel.function("sys_sendfile64")'
> kernel.function("SyS_sendfile64@fs/read_write.c:899")

Right, sys_sendfile and sys_sendfile64 are distinct, but the sys/SyS are
aliases.

>> PS - ppc arguments appear broken in nd_syscall - anyone know why?
> 
> Hmm, what exactly do you mean by broken?

They have incorrect values, e.g.:

GOOD:
$ stap -e 'probe syscall.open { println(argstr) }' -c 'cat /dev/null'
"/etc/ld.so.cache", O_RDONLY
"/lib/libc.so.6", O_RDONLY
"/usr/lib/locale/locale-archive", O_RDONLY|O_LARGEFILE
"/dev/null", O_RDONLY|O_LARGEFILE

BAD:
$ stap -e 'probe nd_syscall.open { println(argstr) }' -c 'cat /dev/null'
<unknown>,
O_RDONLY|O_CREAT|O_DIRECT|O_DIRECTORY|O_LARGEFILE|O_NONBLOCK|O_SYNC|O_TRUNC,
01400000000000010655100
<unknown>,
O_RDONLY|O_CREAT|O_DIRECT|O_DIRECTORY|O_LARGEFILE|O_NONBLOCK|O_SYNC|O_TRUNC,
01400000000000010655100
<unknown>,
O_RDONLY|O_CREAT|O_DIRECT|O_DIRECTORY|O_LARGEFILE|O_NONBLOCK|O_SYNC|O_TRUNC,
01400000000000010655100
<unknown>,
O_RDONLY|O_CREAT|O_DIRECT|O_DIRECTORY|O_LARGEFILE|O_NONBLOCK|O_SYNC|O_TRUNC,
01400000000000010655100