This is the mail archive of the
systemtap@sourceware.org
mailing list for the systemtap project.
Re: SYSTEMTAP TEST RESULTS : Kernel version 2.6.35-rc3 on POWER ppc64 architecture.
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
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.
Then try:
./loc2c-test -e /usr/lib/debug/lib/modules/*/vmlinux 0xc04cea4c fildes
Which should tell how we think fildes needs to be accessed.
Cheers,
Mark