fche changed the topic of #systemtap to: http://sourceware.org/systemtap; email systemtap@sourceware.org if answers here not timely, conversations may be logged
hpt has joined #systemtap
hchiramm has joined #systemtap
ananth has joined #systemtap
nkambo has quit [Ping timeout: 250 seconds]
ravi_ has joined #systemtap
ericlee has quit [Ping timeout: 250 seconds]
ego_ has joined #systemtap
hkshaw has joined #systemtap
nkambo has joined #systemtap
nkambo has quit [Ping timeout: 244 seconds]
srikar_away has joined #systemtap
srikar_away is now known as srikar
hchiramm has quit [Ping timeout: 250 seconds]
nkambo has joined #systemtap
nkambo has quit [Read error: Connection reset by peer]
naveen_ has joined #systemtap
nkambo has joined #systemtap
nkambo has quit [Quit: Good day !]
nkambo has joined #systemtap
nkambo has quit [Quit: Good day !]
nkambo has joined #systemtap
hchiramm has joined #systemtap
nkambo1 has joined #systemtap
nkambo has quit [Ping timeout: 260 seconds]
hpt has quit [Quit: leaving]
pwithnall has joined #systemtap
ericlee has joined #systemtap
hpt has joined #systemtap
hpt has quit [Quit: Lost terminal]
irker366 has joined #systemtap
<irker366>
systemtap: mcermak systemtap.git:refs/heads/mcermak/variance * release-3.0-203-g9b9aff7 / translate.cxx: Make multidimensional pmaps work too. http://tinyurl.com/j9udw7t
scox has quit [Ping timeout: 240 seconds]
mjw has joined #systemtap
ananth has quit [Quit: Leaving]
pwithnall has quit [Remote host closed the connection]
pwithnall has joined #systemtap
ravi_ has quit [Quit: Leaving]
mbenitez has joined #systemtap
mbenitez has quit [Changing host]
mbenitez has joined #systemtap
hkshaw has quit [Ping timeout: 265 seconds]
hkshaw has joined #systemtap
ericlee has quit [Remote host closed the connection]
ph7 has quit [Quit: Leaving.]
ego_ has quit [Quit: Leaving]
ph7 has joined #systemtap
ph7 has quit [Client Quit]
hpt has joined #systemtap
hpt has quit [Quit: Lost terminal]
scox has joined #systemtap
ravi_ has joined #systemtap
drsmith has joined #systemtap
pwithnall has quit [Quit: pwithnall]
ph7 has joined #systemtap
pwithnall has joined #systemtap
ph7 has quit [Quit: Leaving.]
ph7 has joined #systemtap
wcohen_ has quit [Ping timeout: 240 seconds]
tromey has joined #systemtap
brolley has joined #systemtap
<jhg_>
do probes ever get confused as to who they are?
<jhg_>
for instance, I have a probe module("libafs").function("afs_linux_storeproc").return
<jhg_>
when it prints probefunc() string, it says afs_CacheStoreDCaches instead of the expected afs_linux_storeproc
<jhg_>
coincidentally, probe module("libafs").function("afs_CacheStoreDCaches").return is the next probe...
<jhg_>
I changed the order of the probes and afs_CacheStoreDCaches is still what is printed for the probefunc() string. it is the next in the stack call
srikar is now known as srikar_away
<fche>
jhg_, there could be a bug in the vicinity, but it's not familiar at all
<fche>
probefunc() is based on backtracing IIRC so if one function is inlined in another, you might get an unexpected answer
<fche>
try ppfunc() for comparison
* jhg_
tries
<jhg_>
fche: ppfunc() values are the expected ones
<jhg_>
though I suppose it is good to know about the inlining as well
<fche>
see also [man function::probefunc]
wcohen_ has joined #systemtap
<jhg_>
so compiler optimization and such might cause probefunc memory regions to be fuzzy on the edges
<fche>
yup
ravi_ has quit [Quit: Leaving]
ph7 has quit [Quit: Leaving.]
ph7 has joined #systemtap
ph7 has quit [Client Quit]
<jhg_>
fche: is there a clever way to cross reference a kernel module's functions which call kernel functions?
<fche>
could try probing module("foo").function("bar").callees { }
<jhg_>
I'd like to collect statistics for what kernel calls my module does
<jhg_>
hmm. did not know about .callees
<jhg_>
fche: nm -u foo.ko
<jhg_>
hmm
<jhg_>
I want something like this:
<jhg_>
probe module("openafs.ko").callee("<list of nm -u openafs.ko>")
<fche>
I suppose one could write a shell script that does that nm -u, puts it together with (hard-coded? modules.dep-parsing?) candidate module("foo")/kernel functions that may satisfy those -u symbols
<fche>
and synthesize a stap script that probes them all, with a { if (symdata(caller()) !~ "openafs") next }
<fche>
something vaguely like that
<jhg_>
automated boundary detection is the goal
<jhg_>
not sure how useful it would be
hchiramm has quit [Ping timeout: 276 seconds]
<jhg_>
ah... and stap needs both sets of quotes. bash is going to be fun to get the escapes right here. hm.
tromey has quit [Quit: ERC (IRC client for Emacs 25.1.3)]
<jhg_>
heh, I am still stuck on that bash escape of ' issue
<jhg_>
perhaps I ought to try ruby
<jhg_>
or fewer interruptions. heh
<jistone>
jhg_, are you trying to quote a stap script on the command line?
<jhg_>
stap -l $\'kernel.function\(\"$func\"\)\'
<jhg_>
jistone: I am probing a list generated by nm -u openafs.ko
<jhg_>
to see how many are kernel functions that we can tap
<jistone>
jhg_, why do you need to go through "nm"? can't you just wildcard your stap query?
<jistone>
oh, "nm -u", I guess you just want stuff in the kernel that openafs uses?
<jhg_>
jistone: there is probably a more clever way to do what I want...
<jhg_>
jistone: yes
<jhg_>
jistone: probe module("openafs.ko").callee("<list of nm -u openafs.ko>")
<jhg_>
a cross reference of sorts. fche gave an example for how one might do that now using symdata(caller())
<jistone>
yeah, callee works based on debuginfo, and I don't think you'll get that across binaries
<fche>
jhg_, re quoting ... write the .stp script to a file
<fche>
so don't have to wrestle with shell level quoting too
<jistone>
in userspace you could use .plt probes. too bad the kernel is weird and uses ET_REL
<jhg_>
fche: sometimes I just have to do it the hard way. I need to do this type of stuff regularly in bash, and I remember failing years ago to do this. grudge match, of sorts, I suppose =)
<fche>
"doctor, it hurts when I do this" :-)
<jhg_>
jistone: not sure I follow debuginfo vs binary comment
<jhg_>
fche: that's me
<jistone>
I mean the callee debuginfo has to be self-contained (afaik)
<jistone>
it's a dwarf DIE reference, so that has to be in the same binary
<jhg_>
oh... so probably won't work between .ko and kernel then
<jistone>
that's what I suspect
<jhg_>
I haven't tested it
<jhg_>
if it doesn't work, it is another ifcheck I suppose.
<jhg_>
jistone: if you think of any clever ways to explore and discover the kernel module/kernel interface in terms of call and timing statistics, let me know =)
ppetraki has quit [Quit: Ex-Chat]
<jistone>
you basically want ltrace in the kernel
scox has quit [Ping timeout: 276 seconds]
<jistone>
we have the ltrace.stp script, but that uses plt probes