ppc nd_syscall broken (was Re: manual SyS_foo management is unnecessary?)

[David Smith <dsmith at redhat dot com>]

On 06/15/2010 09:21 AM, David Smith wrote:
> On 06/14/2010 05:25 PM, Josh Stone wrote:
>> On 06/14/2010 02:32 PM, David Smith wrote:
>>>> 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.

I got access to a ppc system running RHEL5 (kernel 2.6.18-194.el5,
systemtap 1.1-3.el5).  When I originally ran your example above, I got:

# stap -ve 'probe nd_syscall.open { println(filename) }' -c 'cat /dev/null'
Pass 1: parsed user script and 65 library script(s) using
29184virt/25408res/5440shr kb, in 300usr/0sys/305real ms.
Pass 2: analyzed script: 4 probe(s), 13 function(s), 16 embed(s), 2
global(s) using 29568virt/26112res/5696shr kb, in 20usr/0sys/23real ms.
Pass 3: translated to C into
"/tmp/stapUkWTmX/stap_016c23e1525f681253ac83abbcf7ed8b_18164.c" using
29568virt/26368res/5888shr kb, in 10usr/10sys/9real ms.
cc1: warnings being treated as errors
/tmp/stapUkWTmX/stap_016c23e1525f681253ac83abbcf7ed8b_18164.c: In
function ‘function__stp_get_register_by_offset’:
/tmp/stapUkWTmX/stap_016c23e1525f681253ac83abbcf7ed8b_18164.c:1483:
warning: format ‘%lld’ expects type ‘long long int’, but argument 4 has
type ‘int64_t’
make[1]: ***
[/tmp/stapUkWTmX/stap_016c23e1525f681253ac83abbcf7ed8b_18164.o] Error 1
make: *** [_module_/tmp/stapUkWTmX] Error 2
Pass 4: compiled C into "stap_016c23e1525f681253ac83abbcf7ed8b_18164.ko"
in 2130usr/220sys/2367real ms.
Pass 4: compilation failed.  Try again with another '--vp 0001' option.

This comes from line 74 of tapset/powerpc/registers.stp:

		snprintf(CONTEXT->error_buffer, sizeof(CONTEXT->error_buffer),
				"Bad register offset: %lld", THIS->offset);

After casting THIS->offset, I was also getting weird results like you
were.  I tracked it down to the _stp_arg() function.  Here's the
original function:

function _stp_arg:long (argnum:long, sign_extend:long, truncate:long) {
	val = 0
	if (argnum < 1 || argnum > 8) {
		error(sprintf("Cannot access arg(%d)", argnum))
		return 0
	}

	if (argnum == 1)
		val = u_register("r3")
	else if (argnum == 2)
		val = u_register("r4")
	else if (argnum == 3)
		val = u_register("r5")
	else if (argnum == 4)
		val = u_register("r6")
	else if (argnum == 5)
		val = u_register("r7")
	else if (argnum == 6)
		val = u_register("r8")
	else if (argnum == 7)
		val = u_register("r9")
	else (argnum == 8)
		val = u_register("r10")

	if (truncate) {
		if (sign_extend)
			val = _stp_sign_extend32(val)
		else
			/* High bits may be garbage. */
			val = (val & 0xffffffff);
	}
	return val;
}


The error is in the 'argnum == 8' case - there is a missing 'if'.  That
line should be:

	else if (argnum == 8)
		val = u_register("r10")

Since there was no "if", systemtap grabbed the register you asked for,
then always grabbed the value of r10.  So, that garbage we saw was
really the value of r10.

This is easily fixed, but a bit deeper question is: could the translator
given us a warning or error message with the original code so we could
have easily seen this?

I'll file a bug on this.

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