systemTap 1.0 CROSS COMPILE

systemTap 1.0 CROSS COMPILE

[naresh kamboju]

Hi,

 I have read the release notes of SystemTap-1.0 in NEWS file as CROSS
compilation can be done for other ARCH architectures.

I have been trying to build it for ARM architectures by exporting the
PATH, ARCH, CC and CROSS_COMPILE, however I could not make it work.

Please provide me step to build for CROSS compilation.

env:
ARCH= arm
kernel=2.6.29
gcc= 4.3.3
glibc=2.9


Thank you very much.

Best regards,
Naresh Kamboju

On Wed, Sep 23, 2009 at 8:15 AM, Josh Stone <jistone@redhat.com> wrote:
> The SystemTap team announces release 1.0.
>
>  experimental support for unprivileged users, cross-compiling for
>  foreign architectures, matching C++ class and namespace scopes,
>  reduced runtime memory consumption, reduced dormant overhead in
>  userspace markers, bug fixes, and more...
>
> = Where to get it
>
>  http://sourceware.org/systemtap/ - our project page
>  http://sourceware.org/systemtap/ftp/releases/systemtap-1.0.tar.gz
>  http://koji.fedoraproject.org/koji/packageinfo?packageID=615
>  git tag release-1.0 (commit 6a7aa1a1)
>
> = How to build it
>
>  See the README and NEWS files at
>  http://sourceware.org/git/?p=systemtap.git;a=tree
>  Further information at http://sourceware.org/systemtap/wiki/
>
> = SystemTap frontend (stap) changes
>
> - There is now EXPERIMENTAL support for unprivileged users.  Such users
>  are restricted to only probes and tapset functions that have been
>  explicitly deemed safe.  See the NEWS file for more information on the
>  restrictions and how to enable this feature.
>
> - It is now possible to cross-compile systemtap scripts for foreign
>  architectures, using the new '-a ARCH' and '-B OPT=VALUE' flags.  For
>  example, put arm-linux-gcc etc. into your $PATH, and point systemtap
>  at the target kernel build tree with:
>     stap -a arm -B CROSS_COMPILE=arm-linux- -r /build/tree  [...]
>  The -B option is passed to kbuild make.  -r identifies the already
>  configured/built kernel tree and -a its architecture (kbuild's
>  ARCH=...).  Systemtap will infer -p4.
>
> - stap-start-server now accepts the -r, -R, -I, -B and -a options in
>  order to start a cross compiling server. The server will correctly
>  advertise itself with respect to the kernel release and architecture
>  that it compiles for.
>
> - When specified on stap-client, the -r and -a options will be
>  considered when searching for a suitable server.
>
> - Support output file switching by SIGUSR2. Users can command running
>  stapio to switch output file by sending SIGUSR2.
>
> - Memory consumption for scripts involving many uprobes has been
>  dramatically reduced.
>
> - The systemtap notion of "architecture" now matches the kernel's,
>  rather than that of "uname -m".  This means that 32-bit i386 family
>  are all known as "i386" rather than "i386" or "i686"; "ppc64" as
>  "powerpc"; "s390x" as "s390", and so on.  This is consistent between
>  the new "-a ARCH" flag and the script-level %( arch ... %)
>  conditional.
>
> - A new experimental transport mechanism, using ftrace's ring_buffer,
>  has been added.  This may become the default transport mechanism in
>  future versions of systemtap.  To test this new transport mechanism,
>  define 'STP_USE_RING_BUFFER'.
>
> - Support for recognizing DW_OP_{stack,implicit}_value DWARF expressions
>  as emitted by GCC 4.5.
>
> = SystemTap script language changes
>
> - The function spec for dwarf probes now supports C++ scopes, so you can
>  limit the probes to specific namespaces or classes.  Multiple scopes
>  can be specified, and they will be matched progressively outward.
>      probe process("foo").function("std::vector<*>::*") { }
>      probe process("foo").function("::global_function") { }
>
> - The preprocessor now supports || and && in the conditions.
>  e.g. %( arch == "x86_64" || arch == "ia64" %: ... %)
>
> - It is now possible to define multiple probe aliases with the same
>  name.  A probe will expand to all matching aliases.
>    probe foo = bar { }
>    probe foo = baz { }
>    probe foo { } # expands twice, once to bar and once to baz
>
> = SystemTap tapset changes
>
> - process().mark() probes now use an enabling semaphore to reduce the
>  computation overhead of dormant probes.
>
> - Many functions have been marked for use by unprivileged users.  The
>  general rule is that the functions must only return information that
>  is either globally available or specific to one's own processes.
>
> - The netdev tapset has many new probe points for monitoring network
>  traffic and device configurations.
>
> - The function task_backtrace returns the current hex backtrace of any
>  arbitrary task in the system.
>
> - The function is_myproc returns whether the current process is owned by
>  the same user that launched the systemtap script.
>
> = New script examples
>
> - general/badname.stp     Bad filename filter
> - memory/mmanonpage.stp   Track VM system actions on anonymous pages
> - memory/mmfilepage.stp   Track VM system actions on file-backed pages
> - memory/mmreclaim.stp    Track VM system page reclamation
> - memory/mmwriteback.stp  Track VM system writing to disk
> - network/netdev.stp      Trace activity on network devices
>
> = Contributors for this release
>
>  Breno Leitao, Dave Brolley, David Smith, Eugeniy Meshcheryakov,
>  Frank Ch. Eigler, Jim Keniston, Josh Stone, Maran Pakkirisamy,
>  Mark Wielaard, Masami Hiramatsu, Przemysław Pawełczyk, Robb Romans,
>  Roland McGrath, Stan Cox, Tim Moore, Wenji Huang, William Cohen
>
> = Examples of tested kernel versions
>
>  2.6.9 (el4/i686)
>  2.6.18 (el5/ia64/i686/x86_64)
>  2.6.27.30 (f10/i686/x86_64)
>  2.6.30.5 (f11/i686/x86_64)
>  2.6.31 (f12/i686/x86_64)
>
> = Known issues with this release
>
> - When using the systemtap client and server udp port 5353 must be open
>  in your firewall in order for the clent to find servers using
>  avahi-browse.
>
> - Some kernel crashes continue to be reported when a script probes broad
>  kernel function wildcards.
>
> = Bugs fixed for this release
>
>   2475 Inlines don't match filenames correctly
>   4186 cross-architecture compilation
>   4541 systemtap.stress/current.stp fails to build on ia64
>   5679 inline documentation for scripts/tapsets
>   6866 Extend stp_symbol_snprintf for user space
>   6905 process("a").statement("main@/root/a.c:*") fails
>  10084 dropwatch fails on kernels without kfree_skb tracepoint
>  10155 Switching output files by signal
>  10204 Place userspace markers in systemtap itself
>  10294 .statement("*@FILE:NNN-MMM") line-range probes broken
>  10301 adding '?' to the end of a probe results in a script failure
>  10408 IA-32 - stap unable to decode parameter location using DWARF
>  10417 Support DW_OP_{implicit,stack}_value
>  10424 All tracepoints are unusable if any one header is bad
>  10467 Failure in source:line matching aborts further searching
>  10486 raise default MAXSTRINGLEN on 64-bit hosts
>  10491 Compilation error on running para-callgraph.stp ia64/s390
>  10495 Allow multiple, same name, probe point alias alternatives
>  10499 Missing @file:line info from resolved probes
>  10506 uprobes.ko load broken by module-signing checks
>  10507 overhuge BSS for many-uprobe module
>  10509 Compilation error on systems not having NSS support
>  10512 STAP_PROBES don't work in c++ constructors/destructors
>  10521 Add support for DECLARE_TRACE_WITH_CALLBACK
>  10524 oversize DATA for uprobe-intensive scripts
>  10533 inlined vars are not always found
>  10537 process().function().label() doesn't select multiple inlines
>  10538 Handle anonymous structs and unions nicer
>  10539 ioblktime.stp fails in s390x
>  10543 cache cleaning with cache_mb_limit=0 cleans up new module
>  10544 buildrun.cxx "Error %d ..." messages uninformative
>  10551 pax/grsecurity linux/module.h build compatibility
>  10552 document '-M' (bulk merge) flag
>  10568 translator issue with tapsets
>  10572 stap misses functions with the same name in one CU
>  10573 Identical inline instances may be probed from multiple CUs
>  10574 Some functions resolve to pc=0x0
>  10589 runtime _stp_{dbug,warn,err} should not use _stp_vscnprinf
>  10594 Cache dwarf iterations to improve translator speed
>  10602 REG_IP() used as lvalue fails on s390x, probably ia64
>  10604 new memory examples fail when mm_* tracepoints unavailable.
>  10605 Unknown symbol in module error (Unknown symbol si_swapinfo)
>  10608 don't attempt 32-bit syscall tests without 32-bit devel env.
>  10613 32-bit statfs [ustat] test fails on 2.6.30 kernels
>  10617 make "make uninstall" work
>  10618 Unable to find member 'nr_sectors' for struct request
>  10642 improve performance of .return saved-$variable translation
>
> = Test results on various systems
>
> - After running "sudo make installcheck" from the test suite, on a
>  suitably equipped machine (kernel debugging data and other stuff
>  installed), you should see 1000-1100 passes and a small handful of
>  failures.
>
>

Re: systemTap 1.0 CROSS COMPILE

[Frank Ch. Eigler]

naresh kamboju <naresh.kernel@gmail.com> writes:

> I have been trying to build it for ARM architectures by exporting the
> PATH, ARCH, CC and CROSS_COMPILE, however I could not make it work.

You need to provide more details: exact commands and error messages.
http://sourceware.org/systemtap/wiki/HowToReportBugs

> Please provide me step to build for CROSS compilation.

The "NEWS" file provides compact steps for having a normal native
systemtap binary build probe modules for a different architecture.
This is intended to be useful to have a network-central
script-compiler server that can create modules for a variety of
clients.  Among others things, this requires cross-compilers and a
cross-configured kernel build tree.  Is this the kind of
cross-compilation you had in mind?

- FChE

Re: systemTap 1.0 CROSS COMPILE

[naresh kamboju]

Hi Frank,

Thanks for your quick reply.

I did not find any documentation for CROSS compilation.
Here cross compilation means I have installed ARM tool chain under the
/usr/loca/arm/
Currently I am not using client/server mechanism.

I have to build and install stap and staprun binaries on the Host
Machine by using cross compilation.I’ll use stap to build .ko files
and copy on the target arm architecture board and insert and execute
the module with staprun. Target arm architecture will use (nfs )
network file system of host.
All these operation will be in text mode. I am not using Systemtap GUI.

Steps I have executed
1.	Downloaded and un tar  systemtap-1.0.tar.gz
2.	copy elfutills (v 0.131) to systemtap-1.0
3.	export PATH=/usr/local/arm/:$PATH
4.	export ARCH=arm
5.	export CROSS_COMPILE=/usr/local/arm/arm-dev-
6.	export CC=/usr/local/arm/arm-dev-gcc
7.	“./configure --host=i686-pc-linux-gnueabi --prefix=/usr/local/arm/
--with-elfutils=elfutils”
8.	make
9.	make install

Created stap and staprun files are of X86 arch not ARM architecture.

I am not sure about the steps I have used to compile.

Please give steps or any links to cross compile and install systemtap

ARCH= arm
kernel=2.6.29
gcc= 4.3.3
glibc=2.9


Thank you very much.


Best regards
Naresh Kamboju


On Mon, Oct 26, 2009 at 9:51 PM, Frank Ch. Eigler <fche@redhat.com> wrote:
> naresh kamboju <naresh.kernel@gmail.com> writes:
>
>> I have been trying to build it for ARM architectures by exporting the
>> PATH, ARCH, CC and CROSS_COMPILE, however I could not make it work.
>
> You need to provide more details: exact commands and error messages.
> http://sourceware.org/systemtap/wiki/HowToReportBugs
>
>> Please provide me step to build for CROSS compilation.
>
> The "NEWS" file provides compact steps for having a normal native
> systemtap binary build probe modules for a different architecture.
> This is intended to be useful to have a network-central
> script-compiler server that can create modules for a variety of
> clients.  Among others things, this requires cross-compilers and a
> cross-configured kernel build tree.  Is this the kind of
> cross-compilation you had in mind?
>
> - FChE
>

Re: systemTap 1.0 CROSS COMPILE

[Frank Ch. Eigler]

naresh kamboju <naresh.kernel@gmail.com> writes:

> [...]  I have to build and install stap and staprun binaries on the
> Host Machine by using cross compilation.  I'll use stap to build .ko
> files and copy on the target arm architecture board and insert and
> execute the module with staprun. [...]

OK.  Recall that systemtap is itself a translator/compiler, so in fact
we have several possible "crossings":

1) the machine where systemtap itself is compiled
2) the machine where systemtap is *run*, to translate scripts to .ko's
3) the machine where the modules are run via staprun

The recent cross-architecture enhancements were for the 2->3 crossing,
so wherevever systemtap was run, it could create output .ko's for a
different architecture.

We have not tried to do 1->2 (for stap) or 1->3 (for staprun) itself,
so that we have been expecting systemtap itself (or at least staprun)
to be built natively (on your ARM machine).  

OTOH it should be possible to cross-compile systemtap (or at least
staprun).

> 7. ./configure --host=i686-pc-linux-gnueabi --prefix=/usr/local/arm/
> --with-elfutils=elfutils...

Try instead

.../configure --target=arm... --prefix=... --with-elfutils=... --disable-translator


- FChE

Re: systemTap 1.0 CROSS COMPILE

[naresh kamboju]

Hi,

If any body compiled on PPC (PowerPC) please share the step to cross compile.

Best regards,
Naresh Kamboju

On Tue, Oct 27, 2009 at 1:26 AM, Frank Ch. Eigler <fche@redhat.com> wrote:
> naresh kamboju <naresh.kernel@gmail.com> writes:
>
>> [...]  I have to build and install stap and staprun binaries on the
>> Host Machine by using cross compilation.  I'll use stap to build .ko
>> files and copy on the target arm architecture board and insert and
>> execute the module with staprun. [...]
>
> OK.  Recall that systemtap is itself a translator/compiler, so in fact
> we have several possible "crossings":
>
> 1) the machine where systemtap itself is compiled
> 2) the machine where systemtap is *run*, to translate scripts to .ko's
> 3) the machine where the modules are run via staprun
>
> The recent cross-architecture enhancements were for the 2->3 crossing,
> so wherevever systemtap was run, it could create output .ko's for a
> different architecture.
>
> We have not tried to do 1->2 (for stap) or 1->3 (for staprun) itself,
> so that we have been expecting systemtap itself (or at least staprun)
> to be built natively (on your ARM machine).
>
> OTOH it should be possible to cross-compile systemtap (or at least
> staprun).
>
>> 7. ./configure --host=i686-pc-linux-gnueabi --prefix=/usr/local/arm/
>> --with-elfutils=elfutils...
>
> Try instead
>
> .../configure --target=arm... --prefix=... --with-elfutils=... --disable-translator
>
>
> - FChE
>

Re: systemTap 1.0 CROSS COMPILE

[Ananth N Mavinakayanahalli]

On Wed, Oct 28, 2009 at 12:14:17PM +0530, naresh kamboju wrote:
> Hi,
> 
> If any body compiled on PPC (PowerPC) please share the step to cross compile.

We have compiled POWERPC (64bit) directly... no cross-compile.

Ananth

Re: systemTap 1.0 CROSS COMPILE

[naresh kamboju]

Hi Frank,

On Tue, Oct 27, 2009 at 1:26 AM, Frank Ch. Eigler <fche@redhat.com> wrote:
> naresh kamboju <naresh.kernel@gmail.com> writes:
>
>> [...]  I have to build and install stap and staprun binaries on the
>> Host Machine by using cross compilation.  I'll use stap to build .ko
>> files and copy on the target arm architecture board and insert and
>> execute the module with staprun. [...]
>
> 1) the machine where systemtap itself is compiled
> 2) the machine where systemtap is *run*, to translate scripts to .ko's
> 3) the machine where the modules are run via staprun
>
Yes,
I have same idea.
Here systemtap build will build the stap binary which can be used to
compile .stp file and it will create .ko files which can be insert
able for a given architecture on the host machine.


HOST:
$export PATH=/usr/local/arm
$export CC=/usr/loca/arm-gcc
Stap –vv –p4 –r 2.6.29-arm-XXX –m helloworld helloworld.stp
Pass1:
Pass2:
Pass3:
Pass4:
helloworld.ko is created.

Transfer the helloworld.ko to arm target Machine and run/insert using staprun

TARGET:
#scp naresh@host-machine:/home/naresh/systemtap/helloworld.ko .
#staprun helloworld.ko
hello world
#

> The recent cross-architecture enhancements were for the 2->3 crossing,
> so wherevever systemtap was run, it could create output .ko's for a
> different architecture.
Ok got it.
>
> We have not tried to do 1->2 (for stap) or 1->3 (for staprun) itself,
> so that we have been expecting systemtap itself (or at least staprun)
> to be built natively (on your ARM machine).
Can we do any modification to configure or Makefile to make build it from 1->3.

>
> OTOH it should be possible to cross-compile systemtap (or at least
> staprun).
>
>> 7. ./configure --host=i686-pc-linux-gnueabi --prefix=/usr/local/arm/
>> --with-elfutils=elfutils...
>
> Try instead
>
> .../configure --target=arm... --prefix=... --with-elfutils=... --disable-translator
>

I have tried in different ways to cross compile using installed
/usr/local/arm tool chain.
However, the stap and staprun are created in X86 format again.
As per my investigation the configuration file is not recognizing for
cross compilation.
When we do configure as
“./configure --target=arm --prefix=/usr/local/arm/
--with-elfutils=elfutils --disable-translator”

I think we are missing something at configuration part.
Are we sure about configure file is designed to accept cross compilation?

If any body has done cross compilation on host machine to prepare
stap, staprun binaries and libraries required.
Please share the steps.

It would be a great help.

Best regards
Naresh Kamboju


On Tue, Oct 27, 2009 at 1:26 AM, Frank Ch. Eigler <fche@redhat.com> wrote:
> naresh kamboju <naresh.kernel@gmail.com> writes:
>
>> [...]  I have to build and install stap and staprun binaries on the
>> Host Machine by using cross compilation.  I'll use stap to build .ko
>> files and copy on the target arm architecture board and insert and
>> execute the module with staprun. [...]
>
> OK.  Recall that systemtap is itself a translator/compiler, so in fact
> we have several possible "crossings":
>
> 1) the machine where systemtap itself is compiled
> 2) the machine where systemtap is *run*, to translate scripts to .ko's
> 3) the machine where the modules are run via staprun
>
> The recent cross-architecture enhancements were for the 2->3 crossing,
> so wherevever systemtap was run, it could create output .ko's for a
> different architecture.
>
> We have not tried to do 1->2 (for stap) or 1->3 (for staprun) itself,
> so that we have been expecting systemtap itself (or at least staprun)
> to be built natively (on your ARM machine).
>
> OTOH it should be possible to cross-compile systemtap (or at least
> staprun).
>
>> 7. ./configure --host=i686-pc-linux-gnueabi --prefix=/usr/local/arm/
>> --with-elfutils=elfutils...
>
> Try instead
>
> .../configure --target=arm... --prefix=... --with-elfutils=... --disable-translator
>
>
> - FChE
>

Re: systemTap 1.0 CROSS COMPILE

[Frank Ch. Eigler]

Hi -

On Wed, Oct 28, 2009 at 06:23:18PM +0530, naresh kamboju wrote:
> > Try instead
> > .../configure --target=arm... --prefix=... --with-elfutils=... --disable-translator
> 
> I have tried in different ways to cross compile using installed
> /usr/local/arm tool chain.
> However, the stap and staprun are created in X86 format again.

Right, modern autoconf likes to have "--build=HOST --host=TARGET"
instead of "--target=TARGET" like the older ones did.  Anyway, just
having tried this, systemtap's autoconf stuff is not set up properly
for this style of cross-compilation (it fails during one of the
configure file-existence checks).  It may not be a big job to fix it.

In any case, you need far more than a cross gcc to make this work.
You need a full toolchain including cross ld, cross glibc, and cross
any other libraries that staprun may need to link to.  (I'm assuming
you'd only ever try the --disable-translator cross build.)  And you'll
need a cross-configured kernel build tree to build kernel modules
against.

You should consider building staprun natively on the arm box.

- FChE

Re: systemTap 1.0 CROSS COMPILE

[naresh kamboju]

Hi Frank,


Thanks for the valuable information.
The process is going successfully.

Build  .ko on Host machine and insert the .ko with staprun on the Target.

ON HOST: stap
I have build stap on HOST Machine.
(With out any cross compilations)

#./configure --with-elfutils=elfutils/ --prefix=/usr/local/arm/cross/devel
#make
#make install
# cd testsuite
# cd buildok
# stap -a arm -B CROSS_COMPILE=/usr/local/arm/cross/devel/bin/arm-dev-
-p4 -vv -r  2.6.29.4-kzm-arm11-g7b68317 -m  array_size array_size.stp
/*  build pass and array_size.ko */
/* transfer this .ko file to Target Machine */

ON TARGET: staprun.
I have build staprun on Target Machine.

#./configure --with-elfutils=elfutils/ --prefix=/tool/devel/
#make
#make install
/* staprun with .ko build on HOST Machine */
#staprun array_size.ko
#


However, I am not sure the configure --host, -- target, --build options yet.
Let me try these options some other time.

Best regards,
Naresh Kamboju



On Wed, Oct 28, 2009 at 8:18 PM, Frank Ch. Eigler <fche@redhat.com> wrote:
> Hi -
>
> On Wed, Oct 28, 2009 at 06:23:18PM +0530, naresh kamboju wrote:
>> > Try instead
>> > .../configure --target=arm... --prefix=... --with-elfutils=... --disable-translator
>>
>> I have tried in different ways to cross compile using installed
>> /usr/local/arm tool chain.
>> However, the stap and staprun are created in X86 format again.
>
> Right, modern autoconf likes to have "--build=HOST --host=TARGET"
> instead of "--target=TARGET" like the older ones did.  Anyway, just
> having tried this, systemtap's autoconf stuff is not set up properly
> for this style of cross-compilation (it fails during one of the
> configure file-existence checks).  It may not be a big job to fix it.
>
> In any case, you need far more than a cross gcc to make this work.
> You need a full toolchain including cross ld, cross glibc, and cross
> any other libraries that staprun may need to link to.  (I'm assuming
> you'd only ever try the --disable-translator cross build.)  And you'll
> need a cross-configured kernel build tree to build kernel modules
> against.
>
> You should consider building staprun natively on the arm box.
>
> - FChE
>