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]

Follow-up to [Bug translator/14596] New: probe module enhancement request


Colleagues, my co-worker Jim Baxter and I have been trying to get cross-compiled SystemTap scripts to work with modules on Freescale ARMv7 i.MX6.    First I compiled and ran several examples on the target board from http://sourceware.org/systemtap/examples/  just to make sure that the whole machinery was working. The compilation host is an Ubuntu VM.

My goal involves probing modules, so next I tried compiling the file probedrm.stp

      probe module("drm").function("*")
      {print("I am here\n"); exit();}

using the following script

---

STAP_SYSROOT="/build/meibp-2013/build/tmp/sysroots"
CROSS_COMPILE=arm-none-linux-gnueabi-
STP_FILE=probedrm.stp
STP_BASE_NAME=$(basename ${STP_FILE} .stp)

${STAP_SYSROOT}/x86_64-linux/usr/bin/stap $1 -a arm -v -g \
                -R ${STAP_SYSROOT}/mx6q/usr/share/systemtap/runtime \
                --sysroot=${STAP_SYSROOT}/mx6q \
                -B CROSS_COMPILE=${CROSS_COMPILE} \
                -r ${STAP_SYSROOT}/mx6q/usr/src/kernel \
                ${STP_FILE} -d ${STP_BASE_NAME} -m ${STP_BASE_NAME} -p4

----

The result is 

---

[achaiken@sb-ubuntu-1204-64bit systemtap]$ ./compilemodule.sh
Pass 1: parsed user script and 83 library script(s) using 55172virt/22172res/2112shr/20696data kb, in 90usr/10sys/104real ms.
semantic error: while resolving probe point: identifier 'module' at probedrm.stp:1:7
        source: probe module("drm").function("*")
                      ^
semantic error: no match
Pass 2: analyzed script: 0 probe(s), 0 function(s), 0 embed(s), 0 global(s) using 120112virt/23456res/2436shr/21592data kb, in 0usr/80sys/86real ms.
Pass 2: analysis failed.  Try again with another '--vp 01' option.

----

I've tried various configurations of the "-d" and "-r" options as suggested at Bug 14596.     Is the problem that the compiler persistently looks in the localhost /lib/modules?    Given that the target is fairly beefy in computational power, is running stap compiler natively likely an easier strategy in the long run?    

Thanks for any suggestions,
Alison Chaiken
Mentor Embedded Software Division










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