Too larger number in badkprobe test on 32 bits machine.

Too larger number in badkprobe test on 32 bits machine.

[Wenji Huang]

Hi,

The test systemtap.base/badkprobe.exp will fail on 32 bits machine.
[wjhuang@EL4U6-32bits testsuite]$ uname -mr
2.6.28 i686
[wjhuang@EL4U6-32bits testsuite]$ sudo runtest 
systemtap.base/badkprobe.exp --tool_opts install
...
Running ./systemtap.base/badkprobe.exp ...
FAIL: bad kprobe registration (eof)

                 ===  Summary ===

# of unexpected failures        1

In fact, executing the stap script in the test case.
[wjhuang@EL4U6-32bits testsuite]$ sudo stap -g -w -vve 'probe 
kernel.statement(-1).absolute {} probe timer.s(1) { exit() }'
SystemTap translator/driver (version 0.8/0.131 git branch master, commit 
be21f2db + changes)
Copyright (C) 2005-2008 Red Hat, Inc. and others
This is free software; see the source for copying conditions.
Session arch: i686 release: 2.6.28
Created temporary directory "/tmp/staplt6ZIz"
Searched '/usr/local/share/systemtap/tapset/i686/*.stp', found 2
Searched '/usr/local/share/systemtap/tapset/*.stp', found 45
Pass 1: parsed user script and 47 library script(s) in 
630usr/50sys/680real ms.
Pass 2: analyzed script: 2 probe(s), 1 function(s), 0 embed(s), 0 
global(s) in 20usr/20sys/37real ms.
probe_1384 locks nothing
probe_1385 locks nothing
dump_unwindsyms kernel index=0 base=0xc0100000
Found build-id in kernel, length 20, end at 0xc0363400
Pass 3: translated to C into 
"/tmp/staplt6ZIz/stap_84012a21d1a75884e8298817a3e8ad51_390.c" in 
880usr/920sys/1793real ms.
Running make -C "/lib/modules/2.6.28/build" M="/tmp/staplt6ZIz" modules 
 >/dev/null
cc1: warnings being treated as errors
/tmp/staplt6ZIz/stap_84012a21d1a75884e8298817a3e8ad51_390.c:235: 
warning: integer constant is too large for 'unsigned long' type
/tmp/staplt6ZIz/stap_84012a21d1a75884e8298817a3e8ad51_390.c:235: 
warning: large integer implicitly truncated to unsigned type
make[1]: *** 
[/tmp/staplt6ZIz/stap_84012a21d1a75884e8298817a3e8ad51_390.o] Error 1
make: *** [_module_/tmp/staplt6ZIz] Error 2
Pass 4: compiled C into "stap_84012a21d1a75884e8298817a3e8ad51_390.ko" 
in 3640usr/3040sys/6647real ms.
Pass 4: compilation failed.  Try again with another '--vp 0001' option.
Running rm -rf /tmp/staplt6ZIz

Seems "-1" is interpreted as 64-bit number and not appropriate for 32 
bits machine. Change to other number or update translate.cxx to perform 
explicitly truncation ?

Regards,
Wenji

Re: Too larger number in badkprobe test on 32 bits machine.

[Frank Ch. Eigler]

Wenji Huang <wenji.huang@oracle.com> writes:

> [...]
> kernel.statement(-1).absolute {} probe timer.s(1) { exit() }'
> [...]
> /tmp/staplt6ZIz/stap_84012a21d1a75884e8298817a3e8ad51_390.c:235:
> warning: integer constant is too large for 'unsigned long' type
> /tmp/staplt6ZIz/stap_84012a21d1a75884e8298817a3e8ad51_390.c:235:
> warning: large integer implicitly truncated to unsigned type
> make[1]: ***
> [...]
> Seems "-1" is interpreted as 64-bit number and not appropriate for 32
> bits machine. Change to other number or update translate.cxx to
> perform explicitly truncation ?

Yeah, translate.cxx could do it - the trick is finding a series of
casts that quietly truncates the value.  (Changing the test case to
some other number like 0 would only paper over the problem.)

- FChE

Re: Too larger number in badkprobe test on 32 bits machine.

[Wenji Huang]

Frank Ch. Eigler wrote:
> Wenji Huang <wenji.huang@oracle.com> writes:
> 
>> [...]
>> kernel.statement(-1).absolute {} probe timer.s(1) { exit() }'
>> [...]
>> /tmp/staplt6ZIz/stap_84012a21d1a75884e8298817a3e8ad51_390.c:235:
>> warning: integer constant is too large for 'unsigned long' type
>> /tmp/staplt6ZIz/stap_84012a21d1a75884e8298817a3e8ad51_390.c:235:
>> warning: large integer implicitly truncated to unsigned type
>> make[1]: ***
>> [...]
>> Seems "-1" is interpreted as 64-bit number and not appropriate for 32
>> bits machine. Change to other number or update translate.cxx to
>> perform explicitly truncation ?
> 
> Yeah, translate.cxx could do it - the trick is finding a series of
> casts that quietly truncates the value.  (Changing the test case to
> some other number like 0 would only paper over the problem.)
> 
> - FChE
> 
Seems the following patch can solve the problem.
diff --git a/tapsets.cxx b/tapsets.cxx
index 20bea45..abc0fae 100644
--- a/tapsets.cxx
+++ b/tapsets.cxx
@@ -5039,7 +5039,7 @@ dwarf_derived_probe_group::emit_module_decls 
(systemtap_session& s)
            assert (p->maxactive_val >= 0 && p->maxactive_val <= USHRT_MAX);
            s.op->line() << " .maxactive_val=" << p->maxactive_val << ",";
          }
-      s.op->line() << " .address=0x" << hex << p->addr << dec << "UL,";
+      s.op->line() << " .address=(unsigned long)0x" << hex << p->addr 
<< dec << "ULL,";
        s.op->line() << " .module=\"" << p->module << "\",";
        s.op->line() << " .section=\"" << p->section << "\",";
        s.op->line() << " .pp=" << lex_cast_qstring 
(*p->sole_location()) << ",";

Did some tests on x86 and x86_64. The good result is achieved. Probe 
kernel.statement(0x123456789) will be truncated into 
kernel.statement(0x12345678) on 32 bits machine.
$ uname -mr
2.6.26 i686
$ sudo stap -g -w -e 'probe kernel.statement(-1).absolute {}probe 
timer.s(1) { exit() }'
WARNING: probe kernel.statement(-1).absolute registration error (rc -22)

Regards,
Wenji