RE: nightly test result of systemtap in ppc64

RE: nightly test result of systemtap in ppc64

[Stone, Joshua I]

On Tuesday, May 09, 2006 10:28 AM, Hien Nguyen wrote:
> [...] /tmp/stapFJBNY9/stap_24868.c: In function `function_probefunc':
> /tmp/stapFJBNY9/stap_24868.c:46131: warning: 'ptr' might be used
> uninitialized in this function

Can you post the generated code for function_probefunc, with line 46131
marked?

Thanks,

Josh

Re: nightly test result of systemtap in ppc64

[Hien Nguyen]

Stone, Joshua I wrote:

>On Tuesday, May 09, 2006 10:28 AM, Hien Nguyen wrote:
>  
>
>>[...] /tmp/stapFJBNY9/stap_24868.c: In function `function_probefunc':
>>/tmp/stapFJBNY9/stap_24868.c:46131: warning: 'ptr' might be used
>>uninitialized in this function
>>    
>>
>
>Can you post the generated code for function_probefunc, with line 46131
>marked?
>
>Thanks,
>
>Josh
>  
>
I initialized *ptr=NULL to get pass the compiler.

nightly test result of systemtap in ppc64

[Hien Nguyen]

Translator test summary

All test passed.

 === systemtap Summary ===

FAIL: kernel.statement(0xc000000000058078) shutdown (eof)

FAIL: absentstats (1 13)


# of expected passes            159
# of unexpected failures        2
# of untested testcases         1

kernel version: 2.6.9-34.12.EL
systemtap translator version: version 0.5.7 built 2006-05-15

Re: nightly test result of systemtap in ppc64

[Hien Nguyen]

Stone, Joshua I wrote:

>I committed a fix - please see if it works for you now.
>
>Josh
>
>
>  
>
Fix verified.

RE: nightly test result of systemtap in ppc64

[Stone, Joshua I]

I committed a fix - please see if it works for you now.

Josh


On Tuesday, May 09, 2006 11:30 AM, Hien Nguyen wrote:
> Stone, Joshua I wrote:
> 
>> On Tuesday, May 09, 2006 11:02 AM, Hien Nguyen wrote:
>> 
>> 
>>> I initialized *ptr=NULL to get pass the compiler.
>>> 
>>> 
>> 
>> Sure, but I would like to know why that error was reported in the
>> first place.  As far as I can see, there's no way for 'ptr' to be
>> used uninitialized.  If I'm missing something, then your fix just
>> means that we'll induce a NULL dereference if there's a problem.
>> 
>> 
>> Josh
>> 
>> 
> Here it is
> 46121 void function_probefunc (struct context* __restrict__ c) {
>   46122   struct function_probefunc_locals *  __restrict__ l =
>   46123     & c->locals[c->nesting].function_probefunc;
>   46124   (void) l;
>   46125   #define CONTEXT c
>   46126   #define THIS l
>   46127   if (0) goto out;
>   46128   l->__retvalue[0] = '\0';
>   46129   {
>   46130      /* pure */
>   46131         char *dst, *ptr, *start;
>   46132         String str;
>   46133         int len = MAXSTRINGLEN;
>   46134
>   46135         start = strstr(CONTEXT->probe_point, "function(\"");
>   46136         if (start) {
>   46137                 ptr = start + 10;
>   46138         } else {
>   46139                 start = strstr(CONTEXT->probe_point,
>   "inline(\""); 46140                 if (start) {
>   46141                         ptr = start + 8;
>   46142                 }
>   46143         }
>   46144         if (start) {
>   46145                 dst = THIS->__retvalue;
>   46146                 while (*ptr != '@' && --len > 0 && *ptr)
>   46147                         *dst++ = *ptr++;
>   46148                 *dst = 0;
>   46149                 goto out;
>   46150         }
>   46151         if (CONTEXT->regs) {
>   46152                 str  = _stp_string_init (0);
>   46153                 _stp_symbol_sprint(str,
>   REG_IP(CONTEXT->regs)); 46154                 start =
>   strstr(_stp_string_ptr(str), " : "); 46155                 if
>   (start) { 46156                         dst = THIS->__retvalue;
>   46157                         ptr = start+3;
>   46158                         while (*ptr != '+' && --len > 0 &&
>   *ptr) 46159                                 *dst++ = *ptr++;
>   46160                         *dst = 0;
>   46161                 }
>   46162                 else {
>   46163                         strlcpy(THIS->__retvalue,
> _stp_string_ptr(str),M        AXSTRINGLEN);
>   46164                 }
>   46165                 goto out;
>   46166         }
>   46167         THIS->__retvalue[0] = '\0';
>   46168
>   46169   }

Re: nightly test result of systemtap in ppc64

[Hien Nguyen]

Stone, Joshua I wrote:

>On Tuesday, May 09, 2006 11:02 AM, Hien Nguyen wrote:
>  
>
>>I initialized *ptr=NULL to get pass the compiler.
>>    
>>
>
>Sure, but I would like to know why that error was reported in the first
>place.  As far as I can see, there's no way for 'ptr' to be used
>uninitialized.  If I'm missing something, then your fix just means that
>we'll induce a NULL dereference if there's a problem.
>
>
>Josh
>  
>
Here it is
46121 void function_probefunc (struct context* __restrict__ c) {
  46122   struct function_probefunc_locals *  __restrict__ l =
  46123     & c->locals[c->nesting].function_probefunc;
  46124   (void) l;
  46125   #define CONTEXT c
  46126   #define THIS l
  46127   if (0) goto out;
  46128   l->__retvalue[0] = '\0';
  46129   {
  46130      /* pure */
  46131         char *dst, *ptr, *start;
  46132         String str;
  46133         int len = MAXSTRINGLEN;
  46134
  46135         start = strstr(CONTEXT->probe_point, "function(\"");
  46136         if (start) {
  46137                 ptr = start + 10;
  46138         } else {
  46139                 start = strstr(CONTEXT->probe_point, "inline(\"");
  46140                 if (start) {
  46141                         ptr = start + 8;
  46142                 }
  46143         }
  46144         if (start) {
  46145                 dst = THIS->__retvalue;
  46146                 while (*ptr != '@' && --len > 0 && *ptr)
  46147                         *dst++ = *ptr++;
  46148                 *dst = 0;
  46149                 goto out;
  46150         }
  46151         if (CONTEXT->regs) {
  46152                 str  = _stp_string_init (0);
  46153                 _stp_symbol_sprint(str, REG_IP(CONTEXT->regs));
  46154                 start = strstr(_stp_string_ptr(str), " : ");
  46155                 if (start) {
  46156                         dst = THIS->__retvalue;
  46157                         ptr = start+3;
  46158                         while (*ptr != '+' && --len > 0 && *ptr)
  46159                                 *dst++ = *ptr++;
  46160                         *dst = 0;
  46161                 }
  46162                 else {
  46163                         strlcpy(THIS->__retvalue, 
_stp_string_ptr(str),M        AXSTRINGLEN);
  46164                 }
  46165                 goto out;
  46166         }
  46167         THIS->__retvalue[0] = '\0';
  46168
  46169   }

RE: nightly test result of systemtap in ppc64

[Stone, Joshua I]

On Tuesday, May 09, 2006 11:02 AM, Hien Nguyen wrote:
> I initialized *ptr=NULL to get pass the compiler.

Sure, but I would like to know why that error was reported in the first
place.  As far as I can see, there's no way for 'ptr' to be used
uninitialized.  If I'm missing something, then your fix just means that
we'll induce a NULL dereference if there's a problem.


Josh

nightly test result of systemtap in ppc64

[Hien Nguyen]

Summary of translator test
 FAIL: /root/stap_testing_200605091522/src/testsuite/buildok/syscall.stp
[...]
/tmp/stapFJBNY9/stap_24868.c: In function `function_probefunc':
/tmp/stapFJBNY9/stap_24868.c:46131: warning: 'ptr' might be used 
uninitialized in this function
make[1]: *** [/tmp/stapFJBNY9/stap_24868.o] Error 1
[....]

=============================================
1 of 143 tests failed
Please report to systemtap@sources.redhat.com
=============================================

  === systemtap Summary ===

# of expected passes            151
# of unexpected failures        1
# of untested testcases         1

kernel version: 2.6.9-34.12.EL
systemtap translator version: version 0.5.7 built 2006-05-09

Re: Nightly test result of systemtap in ppc64

[Frank Ch. Eigler]

Hi -

Hien sent me the ppc64 C and assembly files for his test case.  The
problem is relatively typical for powerpc: TOC overflow.  In this
case, the ".toc1" section, used for storing addresses of string
literals and ordinary non-auto variables, runs out of space after 8k
of them.

We know we have plenty of work to do in improving the quality and
reducing the quantity of C code being generated.  In the mean time,
adding "-fminimal-toc" to the generated ppc64 Makefile CFLAGS should
solve this problem, at the cost of slower performance.

- FChE

Re: Nightly test result of systemtap in ppc64

[Hien Nguyen]

Hien Nguyen wrote:

> Frank Ch. Eigler wrote:
>
>> Hien Nguyen <hien@us.ibm.com> writes:
>>
>>
>>
>>> FAIL: /root/stap_testing_200604241559/src/testsuite/buildok/syscall.stp
>>> This is the output of gcc for the test about.
>>> {standard input}: Assembler messages:
>>> {standard input}:690082: Error: operand out of range
>>> (0x0000000000008000 is not between 0xffffffffffff8000 and
>>> 0x0000000000007fff)
>>> [...]
>>>
>>
>> Could you run this test by hand, with "stap -k ...", then editing
>> TMPDIR/Makefile to add "CFLAGS+=-save-temps", rerunning the kbuild
>> make command, and finally locating the instructions the assembler is
>> complaining about?
>>
>> If they're branches, this could be related to my recent addition of
>> "-freorder-blocks" to the probe object CFLAGS.
>>
>> - FChE
>>
>>
> The offended code look like these
> ld 28,.LC29584-.LCTOC1(30)
> [...]
> ld 0,.LC29595-.LCTOC1(30)
> etc...
>
> Does not look like branches. I tried it without -freorder-blocks with 
> same result. I am going to chase down this problem.
>
If I commented out the following out of the ppc64/syscalls.stp the 
buildok/syscalls.stp built just fine.

probe syscall.compat_sys_setsockopt = 
kernel.function("compat_sys_setsockopt") {
name = "compat_sys_setsockopt"
fd = $fd
level = $level
level_str = _sockopt_level_str($level)
optname = $optname
optname_str = _sockopt_optname_str($optname)
optval_uaddr = $optval
optlen = $optlen
argstr = sprintf("%d, %s, %s, [0x%p], %d", $fd, level_str,
optname_str, optval_uaddr, $optlen)
}
probe syscall.compat_sys_setsockopt.return =
kernel.function("compat_sys_setsockopt").return {
name = "compat_sys_setsockopt"
retstr = returnstr(1)
}

However, I cound not find anything wrong with it. So I copied this 
snippet to another file and renamed the allias to mysyscall and modified 
the syscals.stp

#! stap -up4

probe mysyscall.*, mysyscall.*.return {
if (retstr != "")
printf("%s\n", retstr)
else
printf("%s: %s (%s) = ", execname(), name, argstr)
}
and it built just fine.

I now have two files under tapset/ppc64 syscall.stp and mytest.stp 
(mytest.stp only contains the probe alias for compat_sys_setsockopt) . 
Modified the syscalls.stp test again to include both syscall and 
mysyscall aliases, stap build failed again with the same error reported 
above.

Re: Nightly test result of systemtap in ppc64

[Hien Nguyen]

Frank Ch. Eigler wrote:

>Hien Nguyen <hien@us.ibm.com> writes:
>
>  
>
>>FAIL: /root/stap_testing_200604241559/src/testsuite/buildok/syscall.stp
>>This is the output of gcc for the test about.
>>{standard input}: Assembler messages:
>>{standard input}:690082: Error: operand out of range
>>(0x0000000000008000 is not between 0xffffffffffff8000 and
>>0x0000000000007fff)
>>[...]
>>    
>>
>
>Could you run this test by hand, with "stap -k ...", then editing
>TMPDIR/Makefile to add "CFLAGS+=-save-temps", rerunning the kbuild
>make command, and finally locating the instructions the assembler is
>complaining about?
>
>If they're branches, this could be related to my recent addition of
>"-freorder-blocks" to the probe object CFLAGS.
>
>- FChE
>  
>
The offended code look like these
ld 28,.LC29584-.LCTOC1(30)
[...]
ld 0,.LC29595-.LCTOC1(30)
etc...

Does not look like branches. I tried it without -freorder-blocks with 
same result. I am going to chase down this problem.

Re: Nightly test result of systemtap in ppc64

[Frank Ch. Eigler]

Hien Nguyen <hien@us.ibm.com> writes:

> FAIL: /root/stap_testing_200604241559/src/testsuite/buildok/syscall.stp
> This is the output of gcc for the test about.
> {standard input}: Assembler messages:
> {standard input}:690082: Error: operand out of range
> (0x0000000000008000 is not between 0xffffffffffff8000 and
> 0x0000000000007fff)
> [...]

Could you run this test by hand, with "stap -k ...", then editing
TMPDIR/Makefile to add "CFLAGS+=-save-temps", rerunning the kbuild
make command, and finally locating the instructions the assembler is
complaining about?

If they're branches, this could be related to my recent addition of
"-freorder-blocks" to the probe object CFLAGS.

- FChE

Nightly test result of systemtap in ppc64

[Hien Nguyen]

Translator tests summary

FAIL: /root/stap_testing_200604241559/src/testsuite/buildok/syscall.stp

This is the output of gcc for the test about.

{standard input}: Assembler messages:
{standard input}:690082: Error: operand out of range (0x0000000000008000 
is not between 0xffffffffffff8000 and 0x0000000000007fff)
{standard input}:690093: Error: operand out of range (0x0000000000008008 
is not between 0xffffffffffff8000 and 0x0000000000007fff)
{standard input}:690186: Error: operand out of range (0x0000000000008010 
is not between 0xffffffffffff8000 and 0x0000000000007fff)
{standard input}:690349: Error: operand out of range (0x0000000000008018 
is not between 0xffffffffffff8000 and 0x0000000000007fff)
[snipped ...]


=============================================
1 of 141 tests failed
Please report to systemtap@sources.redhat.com
=============================================


=== systemtap Summary ===

# of expected passes            152
# of untested testcases         1

kernel version: 2.6.9-34.12.EL
systemtap translator version: version 0.5.5 built 2006-04-24

Re: nightly test result of systemtap in ppc64

[Martin Hunt]

On Mon, 2006-04-10 at 16:42 -0400, Frank Ch. Eigler wrote:
> Hien Nguyen <hien@us.ibm.com> writes:
> 
> > powerpc does not like [%lld vs int64_t]
> > but likes this [%lld vs (long long)]
> > or this [%ld vs int64_t]
> > could it be a compiler bug?
> 
> More likely a "pilot error" in the new code.  

If you mean I checked in a new vsnprintf() but not a new snprintf(), you
are right. I'll get that checked in.

When writing vsnprintf(), I changed %lld to expect int64_t instead of
"long long". And then I forgot to also check in a new snprintf(). That's
the reason for the errors.

Martin

Re: nightly test result of systemtap in ppc64

[Roland McGrath]

> More likely a "pilot error" in the new code.  Is "long long" on ppc64
> a 64-bit or 128-bit quantity?  And on x86_64?

It's 64 bits, but is not the same type as "long", which is also 64 bits.
On x86_64 the kernel uses "long long" for s64/u64 (aka int64_t et al), on
ppc64 it uses "long".  There is no big reason to do one or the other, and
there are nit reasons like this one leaning in both directions.  I wouldn't
really want to depend on which choice is made among the various kernel
versions and machines.

Re: nightly test result of systemtap in ppc64

[Frank Ch. Eigler]

Hien Nguyen <hien@us.ibm.com> writes:

> powerpc does not like [%lld vs int64_t]
> but likes this [%lld vs (long long)]
> or this [%ld vs int64_t]
> could it be a compiler bug?

More likely a "pilot error" in the new code.  Is "long long" on ppc64
a 64-bit or 128-bit quantity?  And on x86_64?

- FChE

Re: nightly test result of systemtap in ppc64

[Roland McGrath]

> powerpc does not like
> snprintf (l->__tmp23, MAXSTRINGLEN, "%6lld %s(%lld):", l->__tmp18, 
> l->__tmp21, l->__tmp22);
> but likes this
> snprintf (l->__tmp23, MAXSTRINGLEN, "%6lld %s(%lld):", (long 
> long)l->__tmp18, l->__tmp21, (long long)l->__tmp22);
> or this
> snprintf (l->__tmp23, MAXSTRINGLEN, "%6ld %s(%ld):", l->__tmp18, 
> l->__tmp21, l->__tmp22);
> 
> could it be a compiler bug?

It's not a bug.  The types like int64_t might correspond to long long or to
long, depending on the processor.  On 64-bit machines, long is 64 bits and
so it is used instead of long long in the definition.  The warning tells
you when the source language types don't match, not when their layouts
actually differ (that way you get something useful for portability to
machines where the sizes and layouts may be different from what you are
compiling with right now).

In ISO C99, you use the macros from <inttypes.h> to go with the types,
i.e. PRId64.  The kernel does not define those macros.  I think the easiest
thing here is to just use "long long" in place of int64_t in kernel code.
In the far future, that may one day mean 128 bits or something, but then
lots of kernel code will have to be cleaned up anyway.


Thanks,
Roland

Re: nightly test result of systemtap in ppc64

[Hien Nguyen]

powerpc does not like
snprintf (l->__tmp23, MAXSTRINGLEN, "%6lld %s(%lld):", l->__tmp18, 
l->__tmp21, l->__tmp22);
but likes this
snprintf (l->__tmp23, MAXSTRINGLEN, "%6lld %s(%lld):", (long 
long)l->__tmp18, l->__tmp21, (long long)l->__tmp22);
or this
snprintf (l->__tmp23, MAXSTRINGLEN, "%6ld %s(%ld):", l->__tmp18, 
l->__tmp21, l->__tmp22);

could it be a compiler bug?

Hien Nguyen wrote:

> Translator summary of failed tests
> FAIL: /root/stap_testing_200604101559/src/testsuite/buildok/indent.stp
>
> /tmp/stapUqKBHd/stap_17486.c: In function `function__generic_indent':
> /tmp/stapUqKBHd/stap_17486.c:376: warning: long long int format, 
> int64_t arg (arg 4)
> /tmp/stapUqKBHd/stap_17486.c:376: warning: long long int format, 
> int64_t arg (arg 6)
> /tmp/stapUqKBHd/stap_17486.c:376: warning: long long int format, 
> int64_t arg (arg 4)
> /tmp/stapUqKBHd/stap_17486.c:376: warning: long long int format, 
> int64_t arg (arg 6)
>
> FAIL: /root/stap_testing_200604101559/src/testsuite/buildok/printf.stp
> /tmp/stap5WbDIE/stap_17538.c: In function `probe_0':
> /tmp/stap5WbDIE/stap_17538.c:205: warning: long long int format, 
> int64_t arg (arg 4)
> /tmp/stap5WbDIE/stap_17538.c:205: warning: long long int format, 
> int64_t arg (arg 5)
>
>
> FAIL: /root/stap_testing_200604101559/src/testsuite/buildok/syscall.stp
> [....]
> In function `probe_114':
> /tmp/stapHw1Dhz/stap_17579.c:76840: warning: long long int format, 
> int64_t arg (arg 4)
> /tmp/stapHw1Dhz/stap_17579.c:76840: warning: long long int format, 
> int64_t arg (arg 4)
> /tmp/stapHw1Dhz/stap_17579.c: In function `probe_116':
> /tmp/stapHw1Dhz/stap_17579.c:77271: warning: long long int format, 
> int64_t arg (arg 4)
> /tmp/stapHw1Dhz/stap_17579.c:77271: warning: long long int format, 
> int64_t arg (arg 5)
> [...]
>
> FAIL: /root/stap_testing_200604101559/src/testsuite/buildok/twenty.stp
> prologue found function 'vfs_readdir' = 0xc0000000000d9d0c
> finding location for local 'file' near address c0000000000d9d0c, 
> module bias 0
> semantic error: write to target variable not permitted: identifier 
> '$file' at ../src/testsuite/buildok/twenty.stp:7:2
>
> FAIL: 
> /root/stap_testing_200604101559/src/testsuite/buildok/twentythree.stp
>
> prologue found function 'free_task' = 0xc00000000005bc38
> finding location for local 'tsk' near address c00000000005bc38, module 
> bias 0
> finding location for local 'tsk' near address c00000000005bc38, module 
> bias 0
> semantic error: write to target variable not permitted: identifier 
> '$tsk' at ../src/testsuite/buildok/twentythree.stp:7:2
>
> =============================================
> 5 of 140 tests failed
> Please report to systemtap@sources.redhat.com
> =============================================
>
>
>
> Test suite summary of failed tests
> FAIL: ./systemtap.maps/ix_hist.stp unexpected EOF
> FAIL: syscalls-run (48)
> === systemtap Summary ===
>
> # of expected passes            133
> # of unexpected failures        2
> # of untested testcases         1
>

nightly test result of systemtap in ppc64

[Hien Nguyen]

Translator summary of failed tests
FAIL: /root/stap_testing_200604101559/src/testsuite/buildok/indent.stp

/tmp/stapUqKBHd/stap_17486.c: In function `function__generic_indent':
/tmp/stapUqKBHd/stap_17486.c:376: warning: long long int format, int64_t 
arg (arg 4)
/tmp/stapUqKBHd/stap_17486.c:376: warning: long long int format, int64_t 
arg (arg 6)
/tmp/stapUqKBHd/stap_17486.c:376: warning: long long int format, int64_t 
arg (arg 4)
/tmp/stapUqKBHd/stap_17486.c:376: warning: long long int format, int64_t 
arg (arg 6)

FAIL: /root/stap_testing_200604101559/src/testsuite/buildok/printf.stp
/tmp/stap5WbDIE/stap_17538.c: In function `probe_0':
/tmp/stap5WbDIE/stap_17538.c:205: warning: long long int format, int64_t 
arg (arg 4)
/tmp/stap5WbDIE/stap_17538.c:205: warning: long long int format, int64_t 
arg (arg 5)


FAIL: /root/stap_testing_200604101559/src/testsuite/buildok/syscall.stp
[....]
In function `probe_114':
/tmp/stapHw1Dhz/stap_17579.c:76840: warning: long long int format, 
int64_t arg (arg 4)
/tmp/stapHw1Dhz/stap_17579.c:76840: warning: long long int format, 
int64_t arg (arg 4)
/tmp/stapHw1Dhz/stap_17579.c: In function `probe_116':
/tmp/stapHw1Dhz/stap_17579.c:77271: warning: long long int format, 
int64_t arg (arg 4)
/tmp/stapHw1Dhz/stap_17579.c:77271: warning: long long int format, 
int64_t arg (arg 5)
[...]

FAIL: /root/stap_testing_200604101559/src/testsuite/buildok/twenty.stp
prologue found function 'vfs_readdir' = 0xc0000000000d9d0c
finding location for local 'file' near address c0000000000d9d0c, module 
bias 0
semantic error: write to target variable not permitted: identifier 
'$file' at ../src/testsuite/buildok/twenty.stp:7:2

FAIL: /root/stap_testing_200604101559/src/testsuite/buildok/twentythree.stp

prologue found function 'free_task' = 0xc00000000005bc38
finding location for local 'tsk' near address c00000000005bc38, module 
bias 0
finding location for local 'tsk' near address c00000000005bc38, module 
bias 0
semantic error: write to target variable not permitted: identifier 
'$tsk' at ../src/testsuite/buildok/twentythree.stp:7:2

=============================================
5 of 140 tests failed
Please report to systemtap@sources.redhat.com
=============================================



Test suite summary of failed tests
FAIL: ./systemtap.maps/ix_hist.stp unexpected EOF
FAIL: syscalls-run (48)
 === systemtap Summary ===

# of expected passes            133
# of unexpected failures        2
# of untested testcases         1

Nightly test result of systemtap in ppc64

[Hien Nguyen]

Stap translator summary
FAIL: /root/stap_testing_200603271752/src/testsuite/buildok/twenty.stp
FAIL: /root/stap_testing_200603271752/src/testsuite/buildok/twentythree.stp
=============================================
2 of 140 tests failed
Please report to systemtap@sources.redhat.com
=============================================

Test suite summary
=== systemtap Summary ===

# of expected passes            135

kernel version: 2.6.9-34.EL.root
systemtap translator version: version 0.5.4 built 2006-03-27