This is the mail archive of the systemtap@sourceware.org mailing list for the systemtap project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: help: cross-instrumentation debug


=?GB2312?B?s8K+ss/g?= <chenjx8@gmail.com> writes:

> [...]
> Number 1: in this case, target systems need gcc or other develop
> packet? can target systems only have binary systemtap-runtime and
> utrace patch for kenrel?

Yes.

> Number 2:can system-runtime send output to other process? I know it
> can use '-o' to save output to a file, but maybe I want use like pipe
> to other process...
> e.g. instead "staprun -o outfile foo.ko"  like "staprun foo.ko > output_pro=
> cess"

Sure:
        staprun foo.ko | output_process


> Number 3:this question about userspace application...
> in host system, I compile a userspace like "gcc -g foo foo.c" so I can
> compile debug module. But in target system I copy a binary foo to
> target system, This binary build like "gcc -O3 foo foo.c" and have
> strip deal. [...]

This is not a proper way to use the tool.  You do not need to compile
your application two separate ways.  If systemtap PR9937 were fixed,
stap would certainly indicate the run-time mismatch between the two
different compilations.

The appropriate way to build an application is once:

    gcc -g -O<N> foo.c -o foo

for some value of N.  Use modern gcc for best results.  Then you leave
the original binary on the systemtap development-side machine (where
stap/stap-server are running).  You copy that same binary, optionally
strip it, and install that on the target machine (where
stap-client/staprun are running).


> Number 4:The last one... systemtap VS dtrace I have read dtrace
> instruction, in Solaris dtrace can write D script build probe, but
> use systemtap in target system, only use debug module group as some
> probes because stap strip could not use in target system. lack of
> flexibility...

Part of the difference is that strip on a linux box usually removes
all symbolic information, not just debugging data.  That leaves almost
nothing for systemtap to go on.  Having the debug data around is
desirable should you wish to debug the program with a tool other than
systemtap anyway.


- FChE


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]