* RE: nightly test result of systemtap in ppc64
@ 2006-05-09 17:59 Stone, Joshua I
2006-05-09 18:02 ` Hien Nguyen
0 siblings, 1 reply; 20+ messages in thread
From: Stone, Joshua I @ 2006-05-09 17:59 UTC (permalink / raw)
To: Hien Nguyen; +Cc: SystemTAP, Nguyen, Thang P
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
^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: nightly test result of systemtap in ppc64
2006-05-09 17:59 nightly test result of systemtap in ppc64 Stone, Joshua I
@ 2006-05-09 18:02 ` Hien Nguyen
0 siblings, 0 replies; 20+ messages in thread
From: Hien Nguyen @ 2006-05-09 18:02 UTC (permalink / raw)
To: Stone, Joshua I; +Cc: SystemTAP, Nguyen, Thang P
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.
^ permalink raw reply [flat|nested] 20+ messages in thread
* nightly test result of systemtap in ppc64
@ 2006-05-15 20:44 Hien Nguyen
0 siblings, 0 replies; 20+ messages in thread
From: Hien Nguyen @ 2006-05-15 20:44 UTC (permalink / raw)
To: SystemTAP
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
^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: nightly test result of systemtap in ppc64
2006-05-09 18:46 Stone, Joshua I
@ 2006-05-10 16:19 ` Hien Nguyen
0 siblings, 0 replies; 20+ messages in thread
From: Hien Nguyen @ 2006-05-10 16:19 UTC (permalink / raw)
To: Stone, Joshua I; +Cc: SystemTAP, Nguyen, Thang P
Stone, Joshua I wrote:
>I committed a fix - please see if it works for you now.
>
>Josh
>
>
>
>
Fix verified.
^ permalink raw reply [flat|nested] 20+ messages in thread
* RE: nightly test result of systemtap in ppc64
@ 2006-05-09 18:46 Stone, Joshua I
2006-05-10 16:19 ` Hien Nguyen
0 siblings, 1 reply; 20+ messages in thread
From: Stone, Joshua I @ 2006-05-09 18:46 UTC (permalink / raw)
To: Hien Nguyen; +Cc: SystemTAP, Nguyen, Thang P
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 }
^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: nightly test result of systemtap in ppc64
2006-05-09 18:19 Stone, Joshua I
@ 2006-05-09 18:29 ` Hien Nguyen
0 siblings, 0 replies; 20+ messages in thread
From: Hien Nguyen @ 2006-05-09 18:29 UTC (permalink / raw)
To: Stone, Joshua I; +Cc: SystemTAP, Nguyen, Thang P
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 }
^ permalink raw reply [flat|nested] 20+ messages in thread
* RE: nightly test result of systemtap in ppc64
@ 2006-05-09 18:19 Stone, Joshua I
2006-05-09 18:29 ` Hien Nguyen
0 siblings, 1 reply; 20+ messages in thread
From: Stone, Joshua I @ 2006-05-09 18:19 UTC (permalink / raw)
To: Hien Nguyen; +Cc: SystemTAP, Nguyen, Thang P
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
^ permalink raw reply [flat|nested] 20+ messages in thread
* nightly test result of systemtap in ppc64
@ 2006-05-09 17:28 Hien Nguyen
0 siblings, 0 replies; 20+ messages in thread
From: Hien Nguyen @ 2006-05-09 17:28 UTC (permalink / raw)
To: SystemTAP
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
^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: Nightly test result of systemtap in ppc64
[not found] ` <4458FFA2.3090802@us.ibm.com>
@ 2006-05-07 22:52 ` Frank Ch. Eigler
0 siblings, 0 replies; 20+ messages in thread
From: Frank Ch. Eigler @ 2006-05-07 22:52 UTC (permalink / raw)
To: Hien Nguyen; +Cc: systemtap
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
^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: Nightly test result of systemtap in ppc64
2006-04-24 22:18 ` Hien Nguyen
@ 2006-05-01 21:53 ` Hien Nguyen
[not found] ` <20060503021650.GC11017@redhat.com>
0 siblings, 1 reply; 20+ messages in thread
From: Hien Nguyen @ 2006-05-01 21:53 UTC (permalink / raw)
To: Hien Nguyen; +Cc: Frank Ch. Eigler, SystemTAP
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.
^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: Nightly test result of systemtap in ppc64
2006-04-24 18:55 ` Frank Ch. Eigler
@ 2006-04-24 22:18 ` Hien Nguyen
2006-05-01 21:53 ` Hien Nguyen
0 siblings, 1 reply; 20+ messages in thread
From: Hien Nguyen @ 2006-04-24 22:18 UTC (permalink / raw)
To: Frank Ch. Eigler; +Cc: SystemTAP
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.
^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: Nightly test result of systemtap in ppc64
2006-04-24 18:16 Nightly " Hien Nguyen
@ 2006-04-24 18:55 ` Frank Ch. Eigler
2006-04-24 22:18 ` Hien Nguyen
0 siblings, 1 reply; 20+ messages in thread
From: Frank Ch. Eigler @ 2006-04-24 18:55 UTC (permalink / raw)
To: Hien Nguyen; +Cc: SystemTAP
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
^ permalink raw reply [flat|nested] 20+ messages in thread
* Nightly test result of systemtap in ppc64
@ 2006-04-24 18:16 Hien Nguyen
2006-04-24 18:55 ` Frank Ch. Eigler
0 siblings, 1 reply; 20+ messages in thread
From: Hien Nguyen @ 2006-04-24 18:16 UTC (permalink / raw)
To: SystemTAP
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
^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: nightly test result of systemtap in ppc64
2006-04-10 20:42 ` Frank Ch. Eigler
2006-04-10 20:53 ` Roland McGrath
@ 2006-04-10 21:05 ` Martin Hunt
1 sibling, 0 replies; 20+ messages in thread
From: Martin Hunt @ 2006-04-10 21:05 UTC (permalink / raw)
To: Frank Ch. Eigler; +Cc: Hien Nguyen, SystemTAP
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
^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: nightly test result of systemtap in ppc64
2006-04-10 20:42 ` Frank Ch. Eigler
@ 2006-04-10 20:53 ` Roland McGrath
2006-04-10 21:05 ` Martin Hunt
1 sibling, 0 replies; 20+ messages in thread
From: Roland McGrath @ 2006-04-10 20:53 UTC (permalink / raw)
To: Frank Ch. Eigler; +Cc: Hien Nguyen, SystemTAP
> 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.
^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: nightly test result of systemtap in ppc64
2006-04-10 20:19 ` Hien Nguyen
2006-04-10 20:28 ` Roland McGrath
@ 2006-04-10 20:42 ` Frank Ch. Eigler
2006-04-10 20:53 ` Roland McGrath
2006-04-10 21:05 ` Martin Hunt
1 sibling, 2 replies; 20+ messages in thread
From: Frank Ch. Eigler @ 2006-04-10 20:42 UTC (permalink / raw)
To: Hien Nguyen; +Cc: SystemTAP
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
^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: nightly test result of systemtap in ppc64
2006-04-10 20:19 ` Hien Nguyen
@ 2006-04-10 20:28 ` Roland McGrath
2006-04-10 20:42 ` Frank Ch. Eigler
1 sibling, 0 replies; 20+ messages in thread
From: Roland McGrath @ 2006-04-10 20:28 UTC (permalink / raw)
To: Hien Nguyen; +Cc: SystemTAP
> 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
^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: nightly test result of systemtap in ppc64
2006-04-10 18:30 nightly " Hien Nguyen
@ 2006-04-10 20:19 ` Hien Nguyen
2006-04-10 20:28 ` Roland McGrath
2006-04-10 20:42 ` Frank Ch. Eigler
0 siblings, 2 replies; 20+ messages in thread
From: Hien Nguyen @ 2006-04-10 20:19 UTC (permalink / raw)
To: SystemTAP
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
>
^ permalink raw reply [flat|nested] 20+ messages in thread
* nightly test result of systemtap in ppc64
@ 2006-04-10 18:30 Hien Nguyen
2006-04-10 20:19 ` Hien Nguyen
0 siblings, 1 reply; 20+ messages in thread
From: Hien Nguyen @ 2006-04-10 18:30 UTC (permalink / raw)
To: SystemTAP
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
^ permalink raw reply [flat|nested] 20+ messages in thread
* Nightly test result of systemtap in ppc64
@ 2006-03-27 19:35 Hien Nguyen
0 siblings, 0 replies; 20+ messages in thread
From: Hien Nguyen @ 2006-03-27 19:35 UTC (permalink / raw)
To: SystemTAP
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
^ permalink raw reply [flat|nested] 20+ messages in thread
end of thread, other threads:[~2006-05-15 20:44 UTC | newest]
Thread overview: 20+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2006-05-09 17:59 nightly test result of systemtap in ppc64 Stone, Joshua I
2006-05-09 18:02 ` Hien Nguyen
-- strict thread matches above, loose matches on Subject: below --
2006-05-15 20:44 Hien Nguyen
2006-05-09 18:46 Stone, Joshua I
2006-05-10 16:19 ` Hien Nguyen
2006-05-09 18:19 Stone, Joshua I
2006-05-09 18:29 ` Hien Nguyen
2006-05-09 17:28 Hien Nguyen
2006-04-24 18:16 Nightly " Hien Nguyen
2006-04-24 18:55 ` Frank Ch. Eigler
2006-04-24 22:18 ` Hien Nguyen
2006-05-01 21:53 ` Hien Nguyen
[not found] ` <20060503021650.GC11017@redhat.com>
[not found] ` <4458FFA2.3090802@us.ibm.com>
2006-05-07 22:52 ` Frank Ch. Eigler
2006-04-10 18:30 nightly " Hien Nguyen
2006-04-10 20:19 ` Hien Nguyen
2006-04-10 20:28 ` Roland McGrath
2006-04-10 20:42 ` Frank Ch. Eigler
2006-04-10 20:53 ` Roland McGrath
2006-04-10 21:05 ` Martin Hunt
2006-03-27 19:35 Nightly " Hien Nguyen
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).