Re: manual SyS_foo management is unnecessary?

[David Smith <dsmith at redhat dot com>]

On 06/14/2010 05:25 PM, Josh Stone wrote:
> 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.

That sounds fine to me.  If the testsuite shows no regressions
before/after your changes here, I'd say go for it.

>>> 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

Hmm, I'll try to take a look at this.

-- 
David Smith
dsmith@redhat.com
Red Hat
http://www.redhat.com
256.217.0141 (direct)
256.837.0057 (fax)