error to run systemtap in an ARM platform

error to run systemtap in an ARM platform

[Da Zheng]

Hello,

I cross-compiled systemtap and tried to run it on an ARM platform, but 
got the following error:
chronos@localhost ~ $ sudo stap --vp 01 syscalls_by_pid.stp
semantic error: unresolved arity-4 function: identifier 
'_arch_ptrace_argstr' at /usr/share/systemtap/tapset/aux_syscalls.stp:2234:9
         source:     retval=_arch_ptrace_argstr(request, pid, addr, data)
                            ^
Pass 2: analyzed script: 285 probe(s), 1528 function(s), 21 embed(s), 1 
global(s) using 112076virt/96408res/46364shr kb, in 
3690usr/190sys/4041real ms.
Pass 2: analysis failed.  Try again with another '--vp 01' option.

my script is just a file doing nothing, which is attached in the end of 
the email.
The version of systemtap is 1.5/0.131, I download from 
http://sourceware.org/systemtap/ftp/releases/systemtap-1.5.tar.gz. The 
kernel version is 2.6.38.3.

I got some errors when I cross compile systemtap. At first, configure 
fails, so I have to give the following variables an empty value
     export ac_cv_file__usr_include_nss3=
     export ac_cv_file__usr_include_nss=
     export ac_cv_file__usr_include_nspr4=
     export ac_cv_file__usr_include_nspr=
     export ac_cv_file__usr_include_avahi_client=
     export ac_cv_file__usr_include_avahi_common=
Then I remove -Werror in runtime/staprun/Makefile.in because 
__SDT_COND_SIGNED(wchar_t) in includes/sys/sdt.h generates error. I 
wonder if the complication errors I got have anything to do with the 
runtime error I get.

Does anyone know how to fix the runtime error?

Thanks,
Da


#! /usr/bin/env stap

# Copyright (C) 2006 IBM Corp.
#
# This file is part of systemtap, and is free software.  You can
# redistribute it and/or modify it under the terms of the GNU General
# Public License (GPL); either version 2, or (at your option) any
# later version.

#
# Print the system call count by process ID in descending order.
#


probe begin {
}

probe syscall.* {
}

probe end {
}

Re: error to run systemtap in an ARM platform

[Mark Wielaard]

Hi Da,

On Thu, 2011-07-14 at 17:58 -0700, Da Zheng wrote:
> I cross-compiled systemtap and tried to run it on an ARM platform, but 
> got the following error:
> chronos@localhost ~ $ sudo stap --vp 01 syscalls_by_pid.stp
> semantic error: unresolved arity-4 function: identifier 
> '_arch_ptrace_argstr' at /usr/share/systemtap/tapset/aux_syscalls.stp:2234:9
>          source:     retval=_arch_ptrace_argstr(request, pid, addr, data)
>                             ^
> Pass 2: analyzed script: 285 probe(s), 1528 function(s), 21 embed(s), 1 
> global(s) using 112076virt/96408res/46364shr kb, in 
> 3690usr/190sys/4041real ms.
> Pass 2: analysis failed.  Try again with another '--vp 01' option.

We don't yet have a tapset/arm/aux_syscalls.stp version.
Look at one of the existing tapset/*/aux_syscalls.stp
(i386,ia64,powerpc,s390,x86_64) ones for examples how to write one.

> my script is just a file doing nothing, which is attached in the end of 
> the email.
> The version of systemtap is 1.5/0.131, I download from 
> http://sourceware.org/systemtap/ftp/releases/systemtap-1.5.tar.gz. The 
> kernel version is 2.6.38.3.

You might want to try current git trunk, it had some small fixes that
might be helpful on arm.

> I got some errors when I cross compile systemtap. At first, configure 
> fails, so I have to give the following variables an empty value
>      export ac_cv_file__usr_include_nss3=
>      export ac_cv_file__usr_include_nss=
>      export ac_cv_file__usr_include_nspr4=
>      export ac_cv_file__usr_include_nspr=
>      export ac_cv_file__usr_include_avahi_client=
>      export ac_cv_file__usr_include_avahi_common=

This might be http://sourceware.org/bugzilla/show_bug.cgi?id=13001

> Then I remove -Werror in runtime/staprun/Makefile.in because 
> __SDT_COND_SIGNED(wchar_t) in includes/sys/sdt.h generates error. I 
> wonder if the complication errors I got have anything to do with the 
> runtime error I get.
>
> Does anyone know how to fix the runtime error?

That is fixed in git trunk:
http://sourceware.org/git/?p=systemtap.git;a=commit;h=c02332052959e4213a59ce0ff40354f51506103a

I also needed the following patch to binutils:
http://sourceware.org/ml/binutils/2011-07/msg00118.html

Hope that helps.

Cheers,

Mark

Re: error to run systemtap in an ARM platform

[Da Zheng]

Hello Mark,

On 07/15/11 02:42, Mark Wielaard wrote:
> Hi Da,
>
> On Thu, 2011-07-14 at 17:58 -0700, Da Zheng wrote:
>> I cross-compiled systemtap and tried to run it on an ARM platform, but
>> got the following error:
>> chronos@localhost ~ $ sudo stap --vp 01 syscalls_by_pid.stp
>> semantic error: unresolved arity-4 function: identifier
>> '_arch_ptrace_argstr' at /usr/share/systemtap/tapset/aux_syscalls.stp:2234:9
>>           source:     retval=_arch_ptrace_argstr(request, pid, addr, data)
>>                              ^
>> Pass 2: analyzed script: 285 probe(s), 1528 function(s), 21 embed(s), 1
>> global(s) using 112076virt/96408res/46364shr kb, in
>> 3690usr/190sys/4041real ms.
>> Pass 2: analysis failed.  Try again with another '--vp 01' option.
> We don't yet have a tapset/arm/aux_syscalls.stp version.
> Look at one of the existing tapset/*/aux_syscalls.stp
> (i386,ia64,powerpc,s390,x86_64) ones for examples how to write one.
Thanks. This has been fixed. But I got another problem.
However, my target machine doesn't have a C compiler, so I have to cross 
compile it.
I tried to compile my script with
$ stap -v syscalls_by_pid.stp -a arm -r 
/build/tegra2_seaboard/tmp/portage/sys-kernel/chromeos-kernel-9999/work/chromeos-kernel-9999/build/tegra2_seaboard 
-p 4 -k

But I got the following error:

Pass 1: parsed user script and 73 library script(s) using 
38656virt/20388res/1712shr kb, in 100usr/10sys/105real ms.
Pass 2: analyzed script: 285 probe(s), 18 function(s), 23 embed(s), 1 
global(s) using 159984virt/84836res/2544shr kb, in 
14160usr/1890sys/4383real ms.
Pass 3: translated to C into "/tmp/stapsWo8wq/stap_23913.c" using 
159984virt/87692res/5400shr kb, in 240usr/0sys/237real ms.
cc1: error: unrecognized command line option "-mlittle-endian"
cc1: error: unrecognized command line option "-mapcs"
cc1: error: unrecognized command line option "-mno-sched-prolog"
cc1: error: unrecognized command line option "-mabi=aapcs-linux"
cc1: error: unrecognized command line option "-mno-thumb-interwork"
/tmp/stapsWo8wq/stap_23913.c:1: error: bad value (armv5t) for -march= switch
/tmp/stapsWo8wq/stap_23913.c:1: error: bad value (armv5t) for -mtune= switch
make[3]: *** [/tmp/stapsWo8wq/stap_23913.o] Error 1
make[2]: *** [_module_/tmp/stapsWo8wq] Error 2
make[1]: *** [sub-make] Error 2
make: *** [all] Error 2
Pass 4: compiled C into "stap_23913.ko" in 1770usr/190sys/417real ms.
Pass 4: compilation failed.  Try again with another '--vp 0001' option.
Keeping temporary directory "/tmp/stapsWo8wq"

I use armv7a-cros-linux-gnueabi-gcc to cross compile the kernel and 
other software. How can I specify the compiler for cross compile? I 
tried to set the environment variable CC, but it doesn't work.
Any ideas?

Thanks,
Da

Re: error to run systemtap in an ARM platform

[Frank Ch. Eigler]

Da Zheng <zhengda1936@gmail.com> writes:

> I tried to compile my script with
> $ stap -v syscalls_by_pid.stp -a arm -r
> /build/tegra2_seaboard/tmp/portage/sys-kernel/chromeos-kernel-9999/work/chromeos-kernel-9999/build/tegra2_seaboard -p 4 -k
> [...]
> Pass 3: translated to C into "/tmp/stapsWo8wq/stap_23913.c" using
> 159984virt/87692res/5400shr kb, in 240usr/0sys/237real ms.
> cc1: error: unrecognized command line option "-mlittle-endian"
> cc1: error: unrecognized command line option "-mapcs"
> cc1: error: unrecognized command line option "-mno-sched-prolog"
> cc1: error: unrecognized command line option "-mabi=aapcs-linux"
> cc1: error: unrecognized command line option "-mno-thumb-interwork"
> /tmp/stapsWo8wq/stap_23913.c:1: error: bad value (armv5t) for -march= switch
> /tmp/stapsWo8wq/stap_23913.c:1: error: bad value (armv5t) for -mtune= switch
> [...]
> I use armv7a-cros-linux-gnueabi-gcc to cross compile the kernel and
> other software. How can I specify the compiler for cross compile? I
> tried to set the environment variable CC, but it doesn't work.

How did you tell kbuild to use that compiler?  Environment variables,
or some kernel Makefile edit?  Have you ever built an out-of-tree
kernel module via cross compilation?

- FChE

Re: error to run systemtap in an ARM platform

[William Cohen]

On 07/15/2011 03:59 PM, Da Zheng wrote:
> Hello Mark,
> 
> On 07/15/11 02:42, Mark Wielaard wrote:
>> Hi Da,
>>
>> On Thu, 2011-07-14 at 17:58 -0700, Da Zheng wrote:
>>> I cross-compiled systemtap and tried to run it on an ARM platform, but
>>> got the following error:
>>> chronos@localhost ~ $ sudo stap --vp 01 syscalls_by_pid.stp
>>> semantic error: unresolved arity-4 function: identifier
>>> '_arch_ptrace_argstr' at /usr/share/systemtap/tapset/aux_syscalls.stp:2234:9
>>>           source:     retval=_arch_ptrace_argstr(request, pid, addr, data)
>>>                              ^
>>> Pass 2: analyzed script: 285 probe(s), 1528 function(s), 21 embed(s), 1
>>> global(s) using 112076virt/96408res/46364shr kb, in
>>> 3690usr/190sys/4041real ms.
>>> Pass 2: analysis failed.  Try again with another '--vp 01' option.
>> We don't yet have a tapset/arm/aux_syscalls.stp version.
>> Look at one of the existing tapset/*/aux_syscalls.stp
>> (i386,ia64,powerpc,s390,x86_64) ones for examples how to write one.
> Thanks. This has been fixed. But I got another problem.
> However, my target machine doesn't have a C compiler, so I have to cross compile it.
> I tried to compile my script with
> $ stap -v syscalls_by_pid.stp -a arm -r /build/tegra2_seaboard/tmp/portage/sys-kernel/chromeos-kernel-9999/work/chromeos-kernel-9999/build/tegra2_seaboard -p 4 -k
> 
> But I got the following error:
> 
> Pass 1: parsed user script and 73 library script(s) using 38656virt/20388res/1712shr kb, in 100usr/10sys/105real ms.
> Pass 2: analyzed script: 285 probe(s), 18 function(s), 23 embed(s), 1 global(s) using 159984virt/84836res/2544shr kb, in 14160usr/1890sys/4383real ms.
> Pass 3: translated to C into "/tmp/stapsWo8wq/stap_23913.c" using 159984virt/87692res/5400shr kb, in 240usr/0sys/237real ms.
> cc1: error: unrecognized command line option "-mlittle-endian"
> cc1: error: unrecognized command line option "-mapcs"
> cc1: error: unrecognized command line option "-mno-sched-prolog"
> cc1: error: unrecognized command line option "-mabi=aapcs-linux"
> cc1: error: unrecognized command line option "-mno-thumb-interwork"
> /tmp/stapsWo8wq/stap_23913.c:1: error: bad value (armv5t) for -march= switch
> /tmp/stapsWo8wq/stap_23913.c:1: error: bad value (armv5t) for -mtune= switch
> make[3]: *** [/tmp/stapsWo8wq/stap_23913.o] Error 1
> make[2]: *** [_module_/tmp/stapsWo8wq] Error 2
> make[1]: *** [sub-make] Error 2
> make: *** [all] Error 2
> Pass 4: compiled C into "stap_23913.ko" in 1770usr/190sys/417real ms.
> Pass 4: compilation failed.  Try again with another '--vp 0001' option.
> Keeping temporary directory "/tmp/stapsWo8wq"
> 
> I use armv7a-cros-linux-gnueabi-gcc to cross compile the kernel and other software. How can I specify the compiler for cross compile? I tried to set the environment variable CC, but it doesn't work.
> Any ideas?
> 
> Thanks,
> Da

Hi Da,

I have been doing cross compiles for the fedora arm kernel this week. You might try setting the PATH to include the path to the cross compiler if it isn't part of the normal path and then try something like:

export ARCH=arm
export CROSS_COMPILE=armv5tel-redhat-linux-gnueabi-
make

CROSS_COMPILE should be the prefix of the copmiler used for all the cross compile commands.

I have made a quick wiki page at (still need to format it properly):

http://sourceware.org/systemtap/wiki/SystemtapOnFedoraArm

-Will

Re: error to run systemtap in an ARM platform

[Frank Ch. Eigler]

Hi -

On Fri, Jul 15, 2011 at 01:46:12PM -0700, Da Zheng wrote:
> [...]
> Yes, right now what I can do is to ask stap to keep the source code of 
> the translated module, and then enter the directory of source code and run
> make -C 
> /build/tegra2_seaboard/tmp/portage/sys-kernel/chromeos-kernel-9999/work/chromeos-kernel-9999/build/tegra2_seaboard 
> M=`pwd` ARCH=arm CROSS_COMPILE=armv7a-cros-linux-gnueabi- modules
> It works, but it's not very convenient.

Use the stap -B flag, ie.

% stap -a arm -B CROSS_COMPILE=armv7a-cros-linux-gnueabi- <etc>

- FChE

Re: error to run systemtap in an ARM platform

[Da Zheng]

On 07/15/11 13:45, William Cohen wrote:
> Hi Da,
>
> I have been doing cross compiles for the fedora arm kernel this week. You might try setting the PATH to include the path to the cross compiler if it isn't part of the normal path and then try something like:
>
> export ARCH=arm
> export CROSS_COMPILE=armv5tel-redhat-linux-gnueabi-
> make
>
> CROSS_COMPILE should be the prefix of the copmiler used for all the cross compile commands.
>
> I have made a quick wiki page at (still need to format it properly):
>
> http://sourceware.org/systemtap/wiki/SystemtapOnFedoraArm
I wish I had seen your wiki page earlier. I spent a lot of time to make 
it work.
Thanks,
Da

RE: error to run systemtap in an ARM platform

[Turgis, Frederic]

Hi,

We are making quite good use of systemtap here at TI and try to expand to more teams internally. We use it both through cross and native compilation. We have leveraged mostly v1.3 but we are planning to move to v1.5

- for your "probe syscalls.*" issue, I can tell it was working with v1.3 (we use sometimes syscalls_by_pid.stp example) with some instability at execution in few cases. Since then, sycalls.stp and syscalls2.stp have evolved and contain some architecture specific code. If you can't port it (which shall be the way to go), you can try to revert the commits. OK, not clean but a way to move forward if you really need this.

- http://sourceware.org/systemtap/wiki/SystemtapOnFedoraArm mentions http://omappedia.org/wiki/Systemtap, which corresponds to our experiments on Android, i.e. cross-compilation. Still fedora page is very complet and probably suits you best, use OMAP page as a complement

- https://wiki.linaro.org/Platform/DevPlatform/systemtap is also interesting in its short intro to systemtap and what we require in terms of debug symbols, kernel config... in context of Linaro (i.e. ARM). Some thoughts also about timestamping events and a list of issues discovered when running testsuite on v1.3 (you can see it in mail archive, look for my e-mail)

We don't have a huge community yet on ARM but most of the people whom we show the tool (even customers) recognize the benefits of it and somehow leverage it

Regards
Fred

Frederic Turgis
OMAP Platform Business Unit - OMAP System Engineering - Platform Enablement



>
Texas Instruments France SA, 821 Avenue Jack Kilby, 06270 Villeneuve Loubet. 036 420 040 R.C.S Antibes. Capital de EUR 753.920

-----Original Message-----

> From: systemtap-owner@sourceware.org
> [mailto:systemtap-owner@sourceware.org] On Behalf Of Da Zheng
> Sent: Friday, July 15, 2011 11:29 PM
> To: William Cohen
> Cc: systemtap@sourceware.org
> Subject: Re: error to run systemtap in an ARM platform
>
> On 07/15/11 13:45, William Cohen wrote:
> > Hi Da,
> >
> > I have been doing cross compiles for the fedora arm kernel
> this week. You might try setting the PATH to include the path
> to the cross compiler if it isn't part of the normal path and
> then try something like:
> >
> > export ARCH=arm
> > export CROSS_COMPILE=armv5tel-redhat-linux-gnueabi-
> > make
> >
> > CROSS_COMPILE should be the prefix of the copmiler used for
> all the cross compile commands.
> >
> > I have made a quick wiki page at (still need to format it properly):
> >
> > http://sourceware.org/systemtap/wiki/SystemtapOnFedoraArm
> I wish I had seen your wiki page earlier. I spent a lot of
> time to make it work.
> Thanks,
> Da
>

Re: error to run systemtap in an ARM platform

[William Cohen]

On 07/15/2011 05:28 PM, Da Zheng wrote:
> On 07/15/11 13:45, William Cohen wrote:
>> Hi Da,
>>
>> I have been doing cross compiles for the fedora arm kernel this week. You might try setting the PATH to include the path to the cross compiler if it isn't part of the normal path and then try something like:
>>
>> export ARCH=arm
>> export CROSS_COMPILE=armv5tel-redhat-linux-gnueabi-
>> make
>>
>> CROSS_COMPILE should be the prefix of the copmiler used for all the cross compile commands.
>>
>> I have made a quick wiki page at (still need to format it properly):
>>
>> http://sourceware.org/systemtap/wiki/SystemtapOnFedoraArm
> I wish I had seen your wiki page earlier. I spent a lot of time to make it work.
> Thanks,
> Da

Hi Da,

I just put up the page Friday, so you wouldn't have seen it earlier. Any comments on it would be appreciated. The process is still more complicated that desired for Fedora ARM (and other cross-compiled environments).

-Will

Re: error to run systemtap in an ARM platform

[William Cohen]

On 07/15/2011 08:22 PM, Turgis, Frederic wrote:
> Hi,
> 
> We are making quite good use of systemtap here at TI and try to expand to more teams internally. We use it both through cross and native compilation. We have leveraged mostly v1.3 but we are planning to move to v1.5
> 
> - for your "probe syscalls.*" issue, I can tell it was working with v1.3 (we use sometimes syscalls_by_pid.stp example) with some instability at execution in few cases. Since then, sycalls.stp and syscalls2.stp have evolved and contain some architecture specific code. If you can't port it (which shall be the way to go), you can try to revert the commits. OK, not clean but a way to move forward if you really need this.
> 
> - http://sourceware.org/systemtap/wiki/SystemtapOnFedoraArm mentions http://omappedia.org/wiki/Systemtap, which corresponds to our experiments on Android, i.e. cross-compilation. Still fedora page is very complet and probably suits you best, use OMAP page as a complement
> 
> - https://wiki.linaro.org/Platform/DevPlatform/systemtap is also interesting in its short intro to systemtap and what we require in terms of debug symbols, kernel config... in context of Linaro (i.e. ARM). Some thoughts also about timestamping events and a list of issues discovered when running testsuite on v1.3 (you can see it in mail archive, look for my e-mail)
> 
> We don't have a huge community yet on ARM but most of the people whom we show the tool (even customers) recognize the benefits of it and somehow leverage it
> 
> Regards
> Fred
> 
> Frederic Turgis
> OMAP Platform Business Unit - OMAP System Engineering - Platform Enablement
> 
> 

Hi Turgis,

Thanks for the SystemTap page on  http://omappedia.org/wiki/Systemtap it was very good starting point for me. I wasn't aware of https://wiki.linaro.org/Platform/DevPlatform/systemtap.

Both http://omappedia.org/wiki/Systemtap and https://wiki.linaro.org/Platform/DevPlatform/systemtap mention high resolution timers being something missing. For some of the issues listed on the pages it would good idea to put feature requests to see if some of these could be addressed for arm.

-Will

Re: error to run systemtap in an ARM platform

[Da Zheng]

Hi,

I got another problem. I tried to compile the example desktop.stp in the 
website, but failed.

$ stap --vp 01 -a arm -r 
/build/tegra2_seaboard/tmp/portage/sys-kernel/chromeos-kernel-9999/work/chromeos-kernel-9999/build/tegra2_seaboard 
-p 4 -B CROSS_COMPILE=armv7a-cros-linux-gnueabi- -k desktop.stp
semantic error: failed to retrieve return value location for vfs_read 
(/build/tegra2_seaboard/tmp/portage/sys-kernel/chromeos-kernel-9999/work/chromeos-kernel-9999/fs/read_write.c): 
identifier '$return' at desktop.stp:19:7
         source:   if ($return>0) {
                       ^
semantic error: failed to retrieve return value location for vfs_write 
(/build/tegra2_seaboard/tmp/portage/sys-kernel/chromeos-kernel-9999/work/chromeos-kernel-9999/fs/read_write.c): 
identifier '$return' at :29:7
         source:   if ($return>0) {
                       ^
Pass 2: analyzed script: 6 probe(s), 38 function(s), 10 embed(s), 5 
global(s) using 171832virt/76644res/3076shr kb, in 570usr/60sys/633real ms.
Pass 2: analysis failed.  Try again with another '--vp 01' option.
Keeping temporary directory "/tmp/stapqT2qvo"

At first, I thought the bug might be fixed in the latest version, so I 
download the code from the git repository, built it, but still got the 
same error. I checked tapset/xxx/*.stp, but I didn't find scripts 
mention sys_read or sys_write. How do I fix this error?

BTW, I think the latest version in the git repository has another bug.
If I run ./configure; make, I get
cscommon.h:7:17: error: ssl.h: No such file or directory
I don't know what I should install to have ssl.h
I already have
/usr/include/nss/ssl.h
/usr/include/openssl/ssl.h

It can be compiled if I use --disable-server. However, in my cross 
compiling environment, even though I have already used --disable-server, 
I still get the same compilation error.

Thanks,
Da

Re: error to run systemtap in an ARM platform

[William Cohen]

On 07/18/2011 03:01 PM, Da Zheng wrote:
> Hi,
> 
> I got another problem. I tried to compile the example desktop.stp in the website, but failed.

Do you have a pointer to where you got the desktop.stp script? Is that disktop.stp in the systemtap examples?
Did you compile your kernel with the debug information available?

CONFIG_DEBUG_INFO=y

Also from what I recall some kernel can just include file and line number information, with 
CONFIG_DEBUG_INFO_REDUCED. That is turned off in the kernel .config?


I tried compiling disktop.stp on my machine and got:

export KERNEL_SRC=/home/wcohen/stuff/efikamx/kernel/linux-kernel
stap -a arm -B CROSS_COMPILE=armv7hl-redhat-linux-gnueabi-   -r $KERNEL_SRC -m disktop disktop.stp 


WARNING: kernel release/architecture mismatch with host forces last-pass 4.
In file included from /tmp/stapt1iKiI/disktop.c:4908:0:
/tmp/stapt1iKiI/stap-symbols.h:89496:1: error: large integer implicitly truncated to unsigned type [-Werror=overflow]
cc1: all warnings being treated as errors.


> 
> $ stap --vp 01 -a arm -r /build/tegra2_seaboard/tmp/portage/sys-kernel/chromeos-kernel-9999/work/chromeos-kernel-9999/build/tegra2_seaboard -p 4 -B CROSS_COMPILE=armv7a-cros-linux-gnueabi- -k desktop.stp
> semantic error: failed to retrieve return value location for vfs_read (/build/tegra2_seaboard/tmp/portage/sys-kernel/chromeos-kernel-9999/work/chromeos-kernel-9999/fs/read_write.c): identifier '$return' at desktop.stp:19:7
>         source:   if ($return>0) {
>                       ^
> semantic error: failed to retrieve return value location for vfs_write (/build/tegra2_seaboard/tmp/portage/sys-kernel/chromeos-kernel-9999/work/chromeos-kernel-9999/fs/read_write.c): identifier '$return' at :29:7
>         source:   if ($return>0) {
>                       ^
> Pass 2: analyzed script: 6 probe(s), 38 function(s), 10 embed(s), 5 global(s) using 171832virt/76644res/3076shr kb, in 570usr/60sys/633real ms.
> Pass 2: analysis failed.  Try again with another '--vp 01' option.
> Keeping temporary directory "/tmp/stapqT2qvo"
> 
> At first, I thought the bug might be fixed in the latest version, so I download the code from the git repository, built it, but still got the same error. I checked tapset/xxx/*.stp, but I didn't find scripts mention sys_read or sys_write. How do I fix this error?
> 
> BTW, I think the latest version in the git repository has another bug.
> If I run ./configure; make, I get
> cscommon.h:7:17: error: ssl.h: No such file or directory
> I don't know what I should install to have ssl.h
> I already have
> /usr/include/nss/ssl.h
> /usr/include/openssl/ssl.h
> 
> It can be compiled if I use --disable-server. However, in my cross compiling environment, even though I have already used --disable-server, I still get the same compilation error.
> 
> Thanks,
> Da

You do a "make distclean" and "configure ..." on your cross compiling machine to get rid of the dependencies in .deps. I think that be stale and the reason why you are gitting that error.

-Will

Re: error to run systemtap in an ARM platform

[William Cohen]

On 07/18/2011 04:09 PM, William Cohen wrote:
> 
> I tried compiling disktop.stp on my machine and got:
> 
> export KERNEL_SRC=/home/wcohen/stuff/efikamx/kernel/linux-kernel
> stap -a arm -B CROSS_COMPILE=armv7hl-redhat-linux-gnueabi-   -r $KERNEL_SRC -m disktop disktop.stp 
> 
> 
> WARNING: kernel release/architecture mismatch with host forces last-pass 4.
> In file included from /tmp/stapt1iKiI/disktop.c:4908:0:
> /tmp/stapt1iKiI/stap-symbols.h:89496:1: error: large integer implicitly truncated to unsigned type [-Werror=overflow]
> cc1: all warnings being treated as errors.

Ah, this was and older systemap-1.4 problem. Systemtap from git repository worked fine. Got output like the following on the arm target machine when doing a native build of the kernel:


Mon Jul 18 20:17:15 2011 , Average:1041Kb/sec, Read:    4361Kb, Write:    848Kb

     UID      PID     PPID                       CMD   DEVICE    T        BYTES
     500    15034    15033                       cc1 mmcblk0p2    R      1905597
     500    15041    15040                       cc1 mmcblk0p2    R      1859083
     500    15035    15033                        as mmcblk0p2    R       685410
     500    15034    15033                       cc1 mmcblk0p2    W       667330
     500    15035    15033                        as mmcblk0p2    W       169827
     500    15036    15032                    fixdep mmcblk0p2    W        31390
     500    15038    15032                        mv mmcblk0p2    R         4320
     500    15040    15039                       gcc mmcblk0p2    R         3760
     500    15039    15021                        sh mmcblk0p2    R         2272
     500    15037    15032                        rm mmcblk0p2    R         1248

-Will

Re: error to run systemtap in an ARM platform

[Da Zheng]

Hello,

On 07/18/11 13:09, William Cohen wrote:
> On 07/18/2011 03:01 PM, Da Zheng wrote:
>> Hi,
>>
>> I got another problem. I tried to compile the example desktop.stp in the website, but failed.
> Do you have a pointer to where you got the desktop.stp script? Is that disktop.stp in the systemtap examples?
Yes, http://sourceware.org/systemtap/examples/io/disktop.stp
> Did you compile your kernel with the debug information available?
>
> CONFIG_DEBUG_INFO=y
>
> Also from what I recall some kernel can just include file and line number information, with
> CONFIG_DEBUG_INFO_REDUCED. That is turned off in the kernel .config?
Yes, I have checked .config in 
/build/tegra2_seaboard/tmp/portage/sys-kernel/chromeos-kernel-9999/work/chromeos-kernel-9999/build/tegra2_seaboard, 
where my kernel is compiled.
CONFIG_DEBUG_INFO is on and CONFIG_DEBUG_INFO_REDUCED is turned off.
I think this is not a problem.
>> BTW, I think the latest version in the git repository has another bug.
>> If I run ./configure; make, I get
>> cscommon.h:7:17: error: ssl.h: No such file or directory
>> I don't know what I should install to have ssl.h
>> I already have
>> /usr/include/nss/ssl.h
>> /usr/include/openssl/ssl.h
>>
>> It can be compiled if I use --disable-server. However, in my cross compiling environment, even though I have already used --disable-server, I still get the same compilation error.
>>
>> Thanks,
>> Da
> You do a "make distclean" and "configure ..." on your cross compiling machine to get rid of the dependencies in .deps. I think that be stale and the reason why you are gitting that error.
I have done "make distclean", but I still get the error :(

Best,
Da

RE: error to run systemtap in an ARM platform

[Turgis, Frederic]

Hi,

In fact there was a more detailed mail on testsuite on the 1st of April 2011 where I did not get answer (maybe people throught it was a joke due to the date ;-) ). That is fairly understandable so I was about to follow-up but I moved from Linaro to unexpectingly long customer assignment and team was also too busy to help

The goal we have now is to move to v1.5 and clean all that (already tested fine by some other guy in the team). As Franck suggested, issues shall be transcribed to bugzilla and we can take care of that.

And I also still have to follow-up on remarks about power management related topics but that's another story !

Regards
Fred

Frederic Turgis
OMAP Platform Business Unit - OMAP System Engineering - Platform Enablement



>
Texas Instruments France SA, 821 Avenue Jack Kilby, 06270 Villeneuve Loubet. 036 420 040 R.C.S Antibes. Capital de EUR 753.920

-----Original Message-----

> From: William Cohen [mailto:wcohen@redhat.com]
> Sent: Monday, July 18, 2011 4:12 PM
> To: Turgis, Frederic
> Cc: Da Zheng; systemtap@sourceware.org
> Subject: Re: error to run systemtap in an ARM platform
>
> On 07/15/2011 08:22 PM, Turgis, Frederic wrote:
> > Hi,
> >
> > We are making quite good use of systemtap here at TI and
> try to expand
> > to more teams internally. We use it both through cross and native
> > compilation. We have leveraged mostly v1.3 but we are
> planning to move
> > to v1.5
> >
> > - for your "probe syscalls.*" issue, I can tell it was
> working with v1.3 (we use sometimes syscalls_by_pid.stp
> example) with some instability at execution in few cases.
> Since then, sycalls.stp and syscalls2.stp have evolved and
> contain some architecture specific code. If you can't port it
> (which shall be the way to go), you can try to revert the
> commits. OK, not clean but a way to move forward if you
> really need this.
> >
> > - http://sourceware.org/systemtap/wiki/SystemtapOnFedoraArm
> mentions
> > http://omappedia.org/wiki/Systemtap, which corresponds to our
> > experiments on Android, i.e. cross-compilation. Still
> fedora page is
> > very complet and probably suits you best, use OMAP page as a
> > complement
> >
> > - https://wiki.linaro.org/Platform/DevPlatform/systemtap is also
> > interesting in its short intro to systemtap and what we require in
> > terms of debug symbols, kernel config... in context of Linaro (i.e.
> > ARM). Some thoughts also about timestamping events and a list of
> > issues discovered when running testsuite on v1.3 (you can see it in
> > mail archive, look for my e-mail)
> >
> > We don't have a huge community yet on ARM but most of the
> people whom
> > we show the tool (even customers) recognize the benefits of it and
> > somehow leverage it
> >
> > Regards
> > Fred
> >
> > Frederic Turgis
> > OMAP Platform Business Unit - OMAP System Engineering - Platform
> > Enablement
> >
> >
>
> Hi Turgis,
>
> Thanks for the SystemTap page on
> http://omappedia.org/wiki/Systemtap it was very good starting
> point for me. I wasn't aware of
> https://wiki.linaro.org/Platform/DevPlatform/systemtap.
>
> Both http://omappedia.org/wiki/Systemtap and
> https://wiki.linaro.org/Platform/DevPlatform/systemtap
> mention high resolution timers being something missing. For
> some of the issues listed on the pages it would good idea to
> put feature requests to see if some of these could be
> addressed for arm.
>
> -Will
>

Re: error to run systemtap in an ARM platform

[Zheng Da]

Hello,

I'm still trying to fix the problem.
semantic error: failed to retrieve return value location for vfs_write
(/build/tegra2_seaboard/tmp/portage/sys-kernel/chromeos-kernel-9999/work/chromeos-kernel-9999/fs/read_write.c):
identifier '$return' at read-write.stp:7:6
        source: 	if ($return > 0) {
                	    ^
I'm pretty sure CONFIG_DEBUG_INFO is enabled, and in
/build/tegra2_seaboard/tmp/portage/sys-kernel/chromeos-kernel-9999/work/chromeos-kernel-9999/build/tegra2_seaboard,
a binary file vmlinux is 57MB. It should contain the debug information.

(cr) zhengda@zdpc
/build/tegra2_seaboard/tmp/portage/sys-kernel/chromeos-kernel-9999/work/chromeos-k
ernel-9999/build/tegra2_seaboard $ ls -l vmlinux
-rwxr-xr-x 1 zhengda portage 59419805 Jul 22 20:55 vmlinux

How does systemtap use the debug information? When it compiles the
script, does it need to read the debug information from the kernel
image? or it needs to read the .obj files of the kernel?
Any ideas how to debug the problem?

Thanks,
Da

On Mon, Jul 18, 2011 at 1:41 PM, Da Zheng <zhengda1936@gmail.com> wrote:
> Hello,
>
> On 07/18/11 13:09, William Cohen wrote:
>>
>> On 07/18/2011 03:01 PM, Da Zheng wrote:
>>>
>>> Hi,
>>>
>>> I got another problem. I tried to compile the example desktop.stp in the
>>> website, but failed.
>>
>> Do you have a pointer to where you got the desktop.stp script? Is that
>> disktop.stp in the systemtap examples?
>
> Yes, http://sourceware.org/systemtap/examples/io/disktop.stp
>>
>> Did you compile your kernel with the debug information available?
>>
>> CONFIG_DEBUG_INFO=y
>>
>> Also from what I recall some kernel can just include file and line number
>> information, with
>> CONFIG_DEBUG_INFO_REDUCED. That is turned off in the kernel .config?
>
> Yes, I have checked .config in
> /build/tegra2_seaboard/tmp/portage/sys-kernel/chromeos-kernel-9999/work/chromeos-kernel-9999/build/tegra2_seaboard,
> where my kernel is compiled.
> CONFIG_DEBUG_INFO is on and CONFIG_DEBUG_INFO_REDUCED is turned off.
> I think this is not a problem.
>>>
>>> BTW, I think the latest version in the git repository has another bug.
>>> If I run ./configure; make, I get
>>> cscommon.h:7:17: error: ssl.h: No such file or directory
>>> I don't know what I should install to have ssl.h
>>> I already have
>>> /usr/include/nss/ssl.h
>>> /usr/include/openssl/ssl.h
>>>
>>> It can be compiled if I use --disable-server. However, in my cross
>>> compiling environment, even though I have already used --disable-server, I
>>> still get the same compilation error.
>>>
>>> Thanks,
>>> Da
>>
>> You do a "make distclean" and "configure ..." on your cross compiling
>> machine to get rid of the dependencies in .deps. I think that be stale and
>> the reason why you are gitting that error.
>
> I have done "make distclean", but I still get the error :(
>
> Best,
> Da
>

Re: error to run systemtap in an ARM platform

[Frank Ch. Eigler]

Zheng Da <zhengda1936@gmail.com> writes:

> I'm still trying to fix the problem.
> semantic error: failed to retrieve return value location for vfs_write
> (/build/tegra2_seaboard/tmp/portage/sys-kernel/chromeos-kernel-9999/work/chromeos-kernel-9999/fs/read_write.c):
> identifier '$return' at read-write.stp:7:6
>         source: 	if ($return > 0) {
>                 	    ^ 
> [...]

I believe this message is derived from elfutils, a library used within
systemtap.  (See dwflpp.cxx:literal_stmt_for_return calling into
dwfl_module_return_value_location and follow from there.)  elfutils
tells us where to find return values of functions in the ABI of each
architecture, as a function of types.


> How does systemtap use the debug information? When it compiles the
> script, does it need to read the debug information from the kernel
> image? or it needs to read the .obj files of the kernel?

It looks in the ELF and/or separated-DWARF files for the kernel:
basically the vmlinux and/or vmlinux.debug files.  It does not need
the ordinary object files that were linked together to go into
vmlinux.  (Kernel modules - .ko files - are different.)


> Any ideas how to debug the problem?

In this case, I might try focusing the debugger on the function
arm_return_value_location(), probably in elfutils' libebl_arm.so.

- FChE

Re: error to run systemtap in an ARM platform

[Frank Ch. Eigler]

I wrote:

>> semantic error: failed to retrieve return value location for vfs_write
>> (/build/tegra2_seaboard/tmp/portage/sys-kernel/chromeos-kernel-9999/work/chromeos-kernel-9999/fs/read_write.c):
>> identifier '$return' at read-write.stp:7:6
>>         source: 	if ($return > 0) {
>>                 	    ^ 
>> [...]
>> Any ideas how to debug the problem?
>
> In this case, I might try focusing the debugger on the function
> arm_return_value_location(), probably in elfutils' libebl_arm.so.

For example, you could use a debugger.  Or, with a native
user-space-capable kernel, run stap on stap:

stap .../examples/general/varwatch.stp \
     'process("/usr/lib*/elfutils/libebl_*.so").statement("*return_value*@*:*")' \
      '$$vars$' \
      -c 'stap -p2 read-write.stp'

- FChE

Re: error to run systemtap in an ARM platform

[Mark Wielaard]

On Sat, 2011-07-23 at 15:55 -0700, Zheng Da wrote:
> Hello,
> 
> I'm still trying to fix the problem.
> semantic error: failed to retrieve return value location for vfs_write
> (/build/tegra2_seaboard/tmp/portage/sys-kernel/chromeos-kernel-9999/work/chromeos-kernel-9999/fs/read_write.c):
> identifier '$return' at read-write.stp:7:6
>         source: 	if ($return > 0) {
>                 	    ^

Is this the only probe for which return values aren't available or are
there others? What is your full script for triggering this issue?

> I'm pretty sure CONFIG_DEBUG_INFO is enabled, and in
> /build/tegra2_seaboard/tmp/portage/sys-kernel/chromeos-kernel-9999/work/chromeos-kernel-9999/build/tegra2_seaboard,
> a binary file vmlinux is 57MB. It should contain the debug information.

Would you be able to upload this somewhere so we can inspect the debug
information? This looks like it is just the kernel image, not the
debuginfo, which is often bigger. You can see with stap -vvv what
systemtap is using. e.g.:

focused on module 'kernel' = [0x0xffffffff81000000,
-0x0xffffffff81e64000, bias 0x0
file /usr/lib/debug/lib/modules/2.6.35.13-92.fc14.x86_64/vmlinux ELF
machine |x86_64 (code 62)

> How does systemtap use the debug information? When it compiles the
> script, does it need to read the debug information from the kernel
> image? or it needs to read the .obj files of the kernel?

It processes the debug information (either in the vmlinux image itself
or from a separate debuginfo file) to extract knowledge of where to find
probe points, parameters, variables, return values and types. This is
used during the translate pass to produce the stap module. So that it
isn't necessary at runtime of the module (for this of course the
version/arch of the debuginfo during translate time and the linux kernel
at runtime should match).

Cheers,

Mark

Re: error to run systemtap in an ARM platform

[William Cohen]

On 07/23/2011 06:55 PM, Zheng Da wrote:
> Hello,
> 
> I'm still trying to fix the problem.
> semantic error: failed to retrieve return value location for vfs_write
> (/build/tegra2_seaboard/tmp/portage/sys-kernel/chromeos-kernel-9999/work/chromeos-kernel-9999/fs/read_write.c):
> identifier '$return' at read-write.stp:7:6
>         source: 	if ($return > 0) {
>                 	    ^
> I'm pretty sure CONFIG_DEBUG_INFO is enabled, and in
> /build/tegra2_seaboard/tmp/portage/sys-kernel/chromeos-kernel-9999/work/chromeos-kernel-9999/build/tegra2_seaboard,
> a binary file vmlinux is 57MB. It should contain the debug information.
> 
> (cr) zhengda@zdpc
> /build/tegra2_seaboard/tmp/portage/sys-kernel/chromeos-kernel-9999/work/chromeos-k
> ernel-9999/build/tegra2_seaboard $ ls -l vmlinux
> -rwxr-xr-x 1 zhengda portage 59419805 Jul 22 20:55 vmlinux
> 
> How does systemtap use the debug information? When it compiles the
> script, does it need to read the debug information from the kernel
> image? or it needs to read the .obj files of the kernel?
> Any ideas how to debug the problem?
> 
> Thanks,
> Da



To try to replicate the problem on an arm machine running fedora 13 I ran the current build of systemtap from the git reposository and tried the iostats.stp example which should be accessing the $return:

 ./install/bin/stap -v systemtap/testsuite/systemtap.examples/io/iostats.stp 

This worked without problem on the locally built 2.6.31.14.24-efikamx linux kernel. This is a locally built kernel and systemtap is building things natively rather than attempting a cross compile. This is using:

gcc-4.4.5-2.fc13.armv5tel
elfutils-0.146-1.fc13.armv5tel

The following gives some suggestions on reporting bugs:

http://sourceware.org/systemtap/wiki/HowToReportBugs

These are "kernel("function_name").return"? What does list out as available at that probe point?

stap -L 'kernel("function_name").return' 



-Will

Re: error to run systemtap in an ARM platform

[William Cohen]

On 07/23/2011 06:55 PM, Zheng Da wrote:
> Hello,
> 
> I'm still trying to fix the problem.
> semantic error: failed to retrieve return value location for vfs_write
> (/build/tegra2_seaboard/tmp/portage/sys-kernel/chromeos-kernel-9999/work/chromeos-kernel-9999/fs/read_write.c):
> identifier '$return' at read-write.stp:7:6
>         source: 	if ($return > 0) {
>                 	    ^
> I'm pretty sure CONFIG_DEBUG_INFO is enabled, and in
> /build/tegra2_seaboard/tmp/portage/sys-kernel/chromeos-kernel-9999/work/chromeos-kernel-9999/build/tegra2_seaboard,
> a binary file vmlinux is 57MB. It should contain the debug information.
> 
> (cr) zhengda@zdpc
> /build/tegra2_seaboard/tmp/portage/sys-kernel/chromeos-kernel-9999/work/chromeos-k
> ernel-9999/build/tegra2_seaboard $ ls -l vmlinux
> -rwxr-xr-x 1 zhengda portage 59419805 Jul 22 20:55 vmlinux
> 
> How does systemtap use the debug information? When it compiles the
> script, does it need to read the debug information from the kernel
> image? or it needs to read the .obj files of the kernel?
> Any ideas how to debug the problem?
> 
> Thanks,
> Da

I wonder if this might be Bug 440059 - Missing return value locations support for ARM in elfutils backend

https://bugzilla.redhat.com/show_bug.cgi?id=440059

How old is the version of elfutils you are using?

-Will

Re: error to run systemtap in an ARM platform

[Da Zheng]

On 07/25/11 03:03, Mark Wielaard wrote:
> On Sat, 2011-07-23 at 15:55 -0700, Zheng Da wrote:
>> Hello,
>>
>> I'm still trying to fix the problem.
>> semantic error: failed to retrieve return value location for vfs_write
>> (/build/tegra2_seaboard/tmp/portage/sys-kernel/chromeos-kernel-9999/work/chromeos-kernel-9999/fs/read_write.c):
>> identifier '$return' at read-write.stp:7:6
>>          source: 	if ($return>  0) {
>>                  	    ^
> Is this the only probe for which return values aren't available or are
> there others? What is your full script for triggering this issue?
I think it doesn't work at other probes either, but the translation 
phase just stops here. The full script is as follow:

$ cat read-write.stp
#! /usr/bin/env stap

global write_by_pid;
global read_by_pid;

probe kernel.function("vfs_write").return {
     if ($return > 0) {
         write_by_pid[execname()] = $return
     }
}

probe kernel.function("vfs_read").return {
     if ($return > 0) {
         read_by_pid[execname()] = $return
     }
}

probe timer.s(10) {
     foreach ([cmd] in write_by_pid-)
         printf("%s writes %d bytes\n", cmd, write_by_pid[cmd])
     foreach ([cmd] in read_by_pid-)
         printf("%s reads %d bytes\n", cmd, read_by_pid[cmd])
     exit()
}
>> I'm pretty sure CONFIG_DEBUG_INFO is enabled, and in
>> /build/tegra2_seaboard/tmp/portage/sys-kernel/chromeos-kernel-9999/work/chromeos-kernel-9999/build/tegra2_seaboard,
>> a binary file vmlinux is 57MB. It should contain the debug information.
> Would you be able to upload this somewhere so we can inspect the debug
> information? This looks like it is just the kernel image, not the
> debuginfo, which is often bigger. You can see with stap -vvv what
> systemtap is using. e.g.:
>
> focused on module 'kernel' = [0x0xffffffff81000000,
> -0x0xffffffff81e64000, bias 0x0
> file /usr/lib/debug/lib/modules/2.6.35.13-92.fc14.x86_64/vmlinux ELF
> machine |x86_64 (code 62)
focused on module 'kernel' = [0x0xc0008000, -0x0xc062c7dc, bias 0x0 file 
/build/tegra2_seaboard/tmp/portage/sys-kernel/chromeos-kernel-9999/work/chromeos-kernel-9999/build/tegra2_seaboard/vmlinux 
ELF machine arm*| (code 40)

$ ls -lh 
/build/tegra2_seaboard/tmp/portage/sys-kernel/chromeos-kernel-9999/work/chromeos-kernel-9999/build/tegra2_seaboard/vmlinux
-rwxr-xr-x 1 zhengda portage 57M Jul 25 11:05 
/build/tegra2_seaboard/tmp/portage/sys-kernel/chromeos-kernel-9999/work/chromeos-kernel-9999/build/tegra2_seaboard/vmlinux

You can download it from http://sharesend.com/download/agkdi

Thanks,
Da

Re: error to run systemtap in an ARM platform

[Da Zheng]

On 07/25/11 08:46, William Cohen wrote:
> On 07/23/2011 06:55 PM, Zheng Da wrote:
>> Hello,
>>
>> I'm still trying to fix the problem.
>> semantic error: failed to retrieve return value location for vfs_write
>> (/build/tegra2_seaboard/tmp/portage/sys-kernel/chromeos-kernel-9999/work/chromeos-kernel-9999/fs/read_write.c):
>> identifier '$return' at read-write.stp:7:6
>>          source: 	if ($return>  0) {
>>                  	    ^
>> I'm pretty sure CONFIG_DEBUG_INFO is enabled, and in
>> /build/tegra2_seaboard/tmp/portage/sys-kernel/chromeos-kernel-9999/work/chromeos-kernel-9999/build/tegra2_seaboard,
>> a binary file vmlinux is 57MB. It should contain the debug information.
>>
>> (cr) zhengda@zdpc
>> /build/tegra2_seaboard/tmp/portage/sys-kernel/chromeos-kernel-9999/work/chromeos-k
>> ernel-9999/build/tegra2_seaboard $ ls -l vmlinux
>> -rwxr-xr-x 1 zhengda portage 59419805 Jul 22 20:55 vmlinux
>>
>> How does systemtap use the debug information? When it compiles the
>> script, does it need to read the debug information from the kernel
>> image? or it needs to read the .obj files of the kernel?
>> Any ideas how to debug the problem?
>>
>> Thanks,
>> Da
>
>
> To try to replicate the problem on an arm machine running fedora 13 I ran the current build of systemtap from the git reposository and tried the iostats.stp example which should be accessing the $return:
>
>   ./install/bin/stap -v systemtap/testsuite/systemtap.examples/io/iostats.stp
>
> This worked without problem on the locally built 2.6.31.14.24-efikamx linux kernel. This is a locally built kernel and systemtap is building things natively rather than attempting a cross compile. This is using:
>
> gcc-4.4.5-2.fc13.armv5tel
> elfutils-0.146-1.fc13.armv5tel
I use elfutils-0.131. Maybe the version of elfutils is too low. Let me 
see if I can build a newer version for my platform.
> The following gives some suggestions on reporting bugs:
>
> http://sourceware.org/systemtap/wiki/HowToReportBugs
>
> These are "kernel("function_name").return"? What does list out as available at that probe point?
>
> stap -L 'kernel("function_name").return'
$ stap -a arm -r 
/build/tegra2_seaboard/tmp/portage/sys-kernel/chromeos-kernel-9999/work/chromeos-kernel-9999/build/tegra2_seaboard 
-L 'kernel.function("sys_read").return'
kernel.function("sys_read@/build/tegra2_seaboard/tmp/portage/sys-kernel/chromeos-kernel-9999/work/chromeos-kernel-9999/fs/read_write.c:402").return 
$return:long int $fd:unsigned int $buf:char* $count:size_t $file:struct 
file* $ret:ssize_t

Thanks,
Da

Re: error to run systemtap in an ARM platform

[Da Zheng]

On 07/25/11 10:16, William Cohen wrote:
> On 07/23/2011 06:55 PM, Zheng Da wrote:
>> Hello,
>>
>> I'm still trying to fix the problem.
>> semantic error: failed to retrieve return value location for vfs_write
>> (/build/tegra2_seaboard/tmp/portage/sys-kernel/chromeos-kernel-9999/work/chromeos-kernel-9999/fs/read_write.c):
>> identifier '$return' at read-write.stp:7:6
>>          source: 	if ($return>  0) {
>>                  	    ^
>> I'm pretty sure CONFIG_DEBUG_INFO is enabled, and in
>> /build/tegra2_seaboard/tmp/portage/sys-kernel/chromeos-kernel-9999/work/chromeos-kernel-9999/build/tegra2_seaboard,
>> a binary file vmlinux is 57MB. It should contain the debug information.
>>
>> (cr) zhengda@zdpc
>> /build/tegra2_seaboard/tmp/portage/sys-kernel/chromeos-kernel-9999/work/chromeos-k
>> ernel-9999/build/tegra2_seaboard $ ls -l vmlinux
>> -rwxr-xr-x 1 zhengda portage 59419805 Jul 22 20:55 vmlinux
>>
>> How does systemtap use the debug information? When it compiles the
>> script, does it need to read the debug information from the kernel
>> image? or it needs to read the .obj files of the kernel?
>> Any ideas how to debug the problem?
>>
>> Thanks,
>> Da
> I wonder if this might be Bug 440059 - Missing return value locations support for ARM in elfutils backend
>
> https://bugzilla.redhat.com/show_bug.cgi?id=440059
>
> How old is the version of elfutils you are using?
Problem is solved. I used a latest version of elfutils, and systemtap 
can compile the script now.

Thanks,
Da

Re: error to run systemtap in an ARM platform

[Mark Wielaard]

On Mon, 2011-07-25 at 12:36 -0700, Da Zheng wrote:
> I use elfutils-0.131. Maybe the version of elfutils is too low. Let me 
> see if I can build a newer version for my platform.

O yes, please try with something newer. 0.131 is from 2007.
Latest release is 0.152:
https://fedorahosted.org/releases/e/l/elfutils/0.152/

Re: error to run systemtap in an ARM platform

[William Cohen]

On 07/25/2011 03:55 PM, Da Zheng wrote:
> On 07/25/11 10:16, William Cohen wrote:
>> On 07/23/2011 06:55 PM, Zheng Da wrote:
>>> Hello,
>>>
>>> I'm still trying to fix the problem.
>>> semantic error: failed to retrieve return value location for vfs_write
>>> (/build/tegra2_seaboard/tmp/portage/sys-kernel/chromeos-kernel-9999/work/chromeos-kernel-9999/fs/read_write.c):
>>> identifier '$return' at read-write.stp:7:6
>>>          source:     if ($return>  0) {
>>>                          ^
>>> I'm pretty sure CONFIG_DEBUG_INFO is enabled, and in
>>> /build/tegra2_seaboard/tmp/portage/sys-kernel/chromeos-kernel-9999/work/chromeos-kernel-9999/build/tegra2_seaboard,
>>> a binary file vmlinux is 57MB. It should contain the debug information.
>>>
>>> (cr) zhengda@zdpc
>>> /build/tegra2_seaboard/tmp/portage/sys-kernel/chromeos-kernel-9999/work/chromeos-k
>>> ernel-9999/build/tegra2_seaboard $ ls -l vmlinux
>>> -rwxr-xr-x 1 zhengda portage 59419805 Jul 22 20:55 vmlinux
>>>
>>> How does systemtap use the debug information? When it compiles the
>>> script, does it need to read the debug information from the kernel
>>> image? or it needs to read the .obj files of the kernel?
>>> Any ideas how to debug the problem?
>>>
>>> Thanks,
>>> Da
>> I wonder if this might be Bug 440059 - Missing return value locations support for ARM in elfutils backend
>>
>> https://bugzilla.redhat.com/show_bug.cgi?id=440059
>>
>> How old is the version of elfutils you are using?
> Problem is solved. I used a latest version of elfutils, and systemtap can compile the script now.
> 
> Thanks,
> Da

Hi Da,

Glad to hear that it is working with the newer elfutils. Which particular distribution of linux for arm are you using?

Are you planning on probing modules with systemtap? We have noticed that probing modules does not currently work on arm. There is a bug entry for it: http://sourceware.org/bugzilla/show_bug.cgi?id=13022


-Will

Re: error to run systemtap in an ARM platform

[Da Zheng]

On 07/26/11 07:03, William Cohen wrote:
> On 07/25/2011 03:55 PM, Da Zheng wrote:
>> On 07/25/11 10:16, William Cohen wrote:
>>> On 07/23/2011 06:55 PM, Zheng Da wrote:
>>>> Hello,
>>>>
>>>> I'm still trying to fix the problem.
>>>> semantic error: failed to retrieve return value location for vfs_write
>>>> (/build/tegra2_seaboard/tmp/portage/sys-kernel/chromeos-kernel-9999/work/chromeos-kernel-9999/fs/read_write.c):
>>>> identifier '$return' at read-write.stp:7:6
>>>>           source:     if ($return>   0) {
>>>>                           ^
>>>> I'm pretty sure CONFIG_DEBUG_INFO is enabled, and in
>>>> /build/tegra2_seaboard/tmp/portage/sys-kernel/chromeos-kernel-9999/work/chromeos-kernel-9999/build/tegra2_seaboard,
>>>> a binary file vmlinux is 57MB. It should contain the debug information.
>>>>
>>>> (cr) zhengda@zdpc
>>>> /build/tegra2_seaboard/tmp/portage/sys-kernel/chromeos-kernel-9999/work/chromeos-k
>>>> ernel-9999/build/tegra2_seaboard $ ls -l vmlinux
>>>> -rwxr-xr-x 1 zhengda portage 59419805 Jul 22 20:55 vmlinux
>>>>
>>>> How does systemtap use the debug information? When it compiles the
>>>> script, does it need to read the debug information from the kernel
>>>> image? or it needs to read the .obj files of the kernel?
>>>> Any ideas how to debug the problem?
>>>>
>>>> Thanks,
>>>> Da
>>> I wonder if this might be Bug 440059 - Missing return value locations support for ARM in elfutils backend
>>>
>>> https://bugzilla.redhat.com/show_bug.cgi?id=440059
>>>
>>> How old is the version of elfutils you are using?
>> Problem is solved. I used a latest version of elfutils, and systemtap can compile the script now.
>>
>> Thanks,
>> Da
> Hi Da,
>
> Glad to hear that it is working with the newer elfutils. Which particular distribution of linux for arm are you using?
It's ChromeOS.
> Are you planning on probing modules with systemtap? We have noticed that probing modules does not currently work on arm. There is a bug entry for it: http://sourceware.org/bugzilla/show_bug.cgi?id=13022
Thanks for letting me know. I guess I won't probing modules.

Thanks,
Da