This is the mail archive of the
systemtap@sourceware.org
mailing list for the systemtap project.
Follow-up to [Bug translator/14596] New: probe module enhancement request
- From: "Chaiken, Alison" <Alison_Chaiken at mentor dot com>
- To: "systemtap at sourceware dot org" <systemtap at sourceware dot org>
- Cc: "Baxter, Jim" <Jim_Baxter at mentor dot com>
- Date: Mon, 17 Jun 2013 18:33:14 +0000
- Subject: Follow-up to [Bug translator/14596] New: probe module enhancement request
- References: <60BA5429A0E1584BA3633194F6F993B5027C77F2 at NA-MBX-03 dot mgc dot mentorg dot com>
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