Re: SYSTEMTAP TEST RESULTS : Kernel version 2.6.35-rc3 on POWER ppc64 architecture.

[Mark Wielaard <mjw at redhat dot com>]

Hi,

I got access to the powerpc machine and the vmlinux debuginfo file.

On Thu, 2010-06-24 at 14:36 -0500, David Smith wrote:
> On 06/24/2010 02:25 PM, Mark Wielaard wrote:
> > On Thu, 2010-06-24 at 14:03 -0500, David Smith wrote:
> >> On 06/24/2010 02:10 AM, Divya Vikas wrote:
> >>>> FAIL: buildok/syscall.stp
> >>>
> >>> This one is failing in syscall.pipe.
> >>>
> >>> Could you run the following command and show me the output: stap -L
> >>> syscall.pipe
> >>>
> >>> semantic error: invalid access '[0]' vs. long int: operator '['
> >>> at /usr/local/share/systemtap/tapset/syscalls2.stp:312:29
> >>>         source: 			pipe0 = user_int(&$fildes[0]);
> >>>                 			                         ^
> >>> semantic error: invalid access '[1]' vs. long int: operator '[' at :313:29
> >>>         source: 			pipe1 = user_int(&$fildes[1]);
> >>>                 			                         ^
> >>> syscall.pipe flags:long flag_str:string name:string fildes_uaddr:long
> >>> pipe0:long pipe1:long argstr:string $fildes:long int $flags:long int
> >>
> >> That one is weird.  Systemtap thinks that '$fildes' is a 'long int', not
> >> a 'long int *'.  From looking at the current kernel source it appears
> >> that $fildes is still a pointer.  I got access to a f12 ppc64 machine
> >> (running 2.6.32.12-115.fc12.ppc64) and it shows the same problems:
> >>
> >> # stap -L 'kernel.function("sys_pipe").call'
> >> kernel.function("SyS_pipe@fs/pipe.c:1117").call $fildes:long int
> >> # stap -L 'kernel.function("sys_pipe2").call'
> >> kernel.function("SyS_pipe2@fs/pipe.c:1101").call $fildes:long int
> >> $flags:long int
> >>
> >> Mark, do you have any ideas here?
> > 
> > Strange. That must the debuginfo is telling us that is the type. Which
> > would indicate a gcc bug I presume.
> > 
> > Could you see what loc2c-test says about it?
> > 
> > When running with stap -vvv -L 'kernel.function("sys_pipe").call' it
> > should output something like: finding location for local 'fildes' near
> > address 0xc04cea4c, module bias 0x0
> 
> finding location for local 'fildes' near address 0xc0000000001e97b0,
> module bias 0x0
> 
> > Then try:
> > ./loc2c-test -e /usr/lib/debug/lib/modules/*/vmlinux 0xc04cea4c
> > 
> > Which should tell what we think can be accessed and what the types are
> > around that address.
> 
> # ./loc2c-test -e
> /usr/lib/debug/lib/modules/2.6.32.12-115.fc12.ppc64/vmlinux
> 0xc0000000001e97b0
>     [125a54c] fs/pipe.c (0x11)
> [...]
>
>         [1264912] SyS_pipe (0x2e): 0xc0000000001e97b0 (fs/pipe.c:1117)
> .. 0xc0000000001e97f4 (fs/pipe.c:1031)
>             fildes                        [1264936]	long int

So we think we need the fildes from DIE 1264936 and think that is a long
int.

eu-readelf -N
--debug-dump=info /usr/lib/debug/lib/modules/2.6.32.12-115.fc12.ppc64/vmlinux

shows us:

 [1264912]    subprogram
             external             Yes
             name                 "SyS_pipe"
             decl_file            1
             decl_line            1117
             prototyped           Yes
             type                 [125a6c9]
             low_pc               +0x00000000001e97b0
             high_pc              +0x00000000001e97f4
             frame_base                         [   0] call_frame_cfa
             sibling              [1264969]
 [1264936]      formal_parameter
               name                 "fildes"
               decl_file            1
               decl_line            1117
               type                 [125a6c9]
               location             location list [2a14d9]

and the type DIE 125a6c9 says:

 [125a6c9]    base_type
             byte_size            8
             encoding             signed (5)
             name                 "long int"

So for some reason gcc encoded the fildes parameter as if it was a long
int. And we just tell the user that fact.

This is from:

 Compilation unit at offset 19244353:
 Version: 2, Abbreviation section offset: 520170, Address size: 8, Offset size: 
4
 [125a54c]  compile_unit
           producer             "GNU C 4.4.3 20100127 (Red Hat 4.4.3-4)"
           language             ISO C89 (1)
           name                 "fs/pipe.c"
           comp_dir             "/usr/src/debug/kernel-2.6.32/linux-2.6.32.ppc64"
           low_pc               +0x4000000000000000
           entry_pc             +0x4000000000000000
           ranges               range list [ bf8f0]
           stmt_list            1127940

Line 1117 (from the 1264936 DIE) says:
SYSCALL_DEFINE1(pipe, int __user *, fildes)

So depending on how SYSCALL_DEFINE1 expands gcc might actually be right.

Cheers,

Mark