This is the mail archive of the
systemtap@sourceware.org
mailing list for the systemtap project.
Re: Follow-up to [Bug translator/14596] New: probe module enhancement request
- From: fche at redhat dot com (Frank Ch. Eigler)
- To: "Chaiken, Alison" <Alison_Chaiken at mentor dot com>
- Cc: "systemtap at sourceware dot org" <systemtap at sourceware dot org>, "Baxter, Jim" <Jim_Baxter at mentor dot com>
- Date: Wed, 19 Jun 2013 07:17:19 -0400
- Subject: Re: Follow-up to [Bug translator/14596] New: probe module enhancement request
- References: <60BA5429A0E1584BA3633194F6F993B5027C77F2 at NA-MBX-03 dot mgc dot mentorg dot com> <60BA5429A0E1584BA3633194F6F993B5027C7832 at NA-MBX-03 dot mgc dot mentorg dot com>
"Chaiken, Alison" <Alison_Chaiken@mentor.com> writes:
> [...]
> probe module("drm").function("*")
> {print("I am here\n"); exit();}
> using the following script
> [...]
> ${STAP_SYSROOT}/x86_64-linux/usr/bin/stap $1 -a arm [...]
> [...]
> semantic error: while resolving probe point: identifier 'module' at probedrm.stp:1:7
> source: probe module("drm").function("*")
> ^
> [...]
> Is the problem that the compiler persistently looks in the localhost /lib/modules?
It shouldn't do that; an strace should clear up where it's looking, and a
stap "--vp 04000" may be enough to give extra information. Maybe something
as simple as the drm.ko file not carrying CONFIG_DEBUG_INFO=y.
> Given that the target is fairly beefy in computational power, is
> running stap compiler natively likely an easier strategy in the long
> run?
They should both be possible.
- FChE