Re: cannot trace user-level code in cross compilation environment

[Zhiwei Ying <zhiwei dot ying at gmail dot com>]

Yes, the binary in in the same path. if the binary is different,
staprun will complain "build-id mismatch"

Here is the detail for my cross-compilation:
cd systemtap-1.4
mkdir runtimebuild
cd runtimebuild
../runtime/staprun/configure --host=/crosstarget --prefix=
make
make install DESTDIR=/xxx

cd runtime/uprobes
#change KDIR in Makefile to crosstarget
make

cp staprun, stapio and uprobes to the board

on the board
# staprun -v traceauto.ko -b 3 -u -c ./hello.
stapio:main:33 Using a buffer of 3 MB.
stapio:start_cmd:200 block briefly
stapio:stp_main_loop:636 detaching pid 2289
stapio:start_cmd:219 execing target_cmd ./hello
hello world
stapio:cleanup_and_exit:403 detach=0
end of tracing
stapio:cleanup_and_exit:420 closing control channel
staprun:remove_module:213 Module traceauto removed

Any help is great appreciated!

Thanks,
Zhiwei

On Sat, Apr 2, 2011 at 2:25 AM, Josh Stone <jistone@redhat.com> wrote:
> On 04/01/2011 02:05 AM, Zhiwei Ying wrote:
>> Hi,
>>
>> I built a systemtap1.4 on ubuntu 10.4 32 bits. And also cross-compile
>> staprun to a develop board with kernel 2.6.35 x86.
>>
>> On the host pc side,
>>
>> stap -r /target-board/kernel xxx.stp -p 4 -m traceauto.ko
>>
>> then copy the traceauto.ko to the board,
>> staprun -u -v -m traceauto.ko -c ./hello
>>
>>
>> xxx.stp
>> probe process("/ddtv/tracedrv/test/dhg/hello/hello").function("*").call
>
> Is your "hello" binary at the same path on the host and target? ?The
> runtime looks for probe targets based on the path, so it will never
> notice if the application is started from a different path.
>
> There's a bug open to address this, but for now the only workaround is
> to copy or link the binary to matching locations on the host and target.
> http://sourceware.org/bugzilla/show_bug.cgi?id=12331
>
> Josh
>