fche changed the topic of #systemtap to: http://sourceware.org/systemtap; email systemtap@sourceware.org if answers here not timely, conversations may be logged
<lorddoskias>
i want to define a probe only if a particular function is present in the kernel the probe is being compiled against, is it possible to perform such a check ?
<lorddoskias>
yep found that in the man page, thaks :)
sona has quit [Ping timeout: 240 seconds]
<lorddoskias>
mjw: and can i filter functions bsed on their caller?
sona has joined #systemtap
__positron has quit [Ping timeout: 240 seconds]
<mjw>
lorddoskias, you could use something like if symname(caller_addr) == "boring_function" next;
<fche>
lorddoskias, also: probe function("foo").callee("bar") --- which puts a probe in function bar, if it's called from foo
<fche>
evaluating basically that function as per mark
wcohen has quit [Ping timeout: 240 seconds]
<lorddoskias>
fche: and what if i have a longer call chaing
<fche>
you'd have to build it up yourself if deeper than that
<lorddoskias>
i can of course manually take the backtrace and check if any of the parent functions are the ones which I'm interested in but I wondered if there was a way for stap do it itself
<lorddoskias>
okay
<fche>
see .callees(DEPTH) too though
ravi has quit [Remote host closed the connection]
sanoj has quit [Ping timeout: 240 seconds]
* mjw
completely forgot about function.callee probes... oops.
<lorddoskias>
i blatantly stole the source of print_syms and hacked my own function :D
orivej has quit [Ping timeout: 268 seconds]
__positron has joined #systemtap
sona has quit [Ping timeout: 260 seconds]
mbenitez has joined #systemtap
mbenitez has joined #systemtap
mbenitez has quit [Changing host]
zodbot has quit [Disconnected by services]
sona has joined #systemtap
wcohen has joined #systemtap
__positron has quit [*.net *.split]
pwithnall____ has quit [*.net *.split]
zodbot has joined #systemtap
brolley has joined #systemtap
__positron has joined #systemtap
orivej has joined #systemtap
wcohen has quit [Remote host closed the connection]
wcohen has joined #systemtap
pwithnall____ has joined #systemtap
sona has quit [Ping timeout: 260 seconds]
ravi has joined #systemtap
pwithnall____ has quit [*.net *.split]
pwithnall____ has joined #systemtap
hkshaw has quit [Ping timeout: 260 seconds]
sona has joined #systemtap
<mjw>
re that post about the source path names. I am hoping Torsten will take a look and maybe provide a patch (he did for elfutils, but I think it should be fixed in systemtap).
<mjw>
But let me know if you want me to deal with it.
hpt has joined #systemtap
tromey has joined #systemtap
<fche>
if you have the time, it'd be great
<mjw>
haha time! You so funny! :)
<fche>
hey then you'll find my dwarf5 sfv ideas just hilarious! :-)
__positron has quit [Ping timeout: 240 seconds]
orivej has quit [Ping timeout: 255 seconds]
orivej has joined #systemtap
csanting has quit [Read error: Connection reset by peer]
csanting has joined #systemtap
sona has quit [Ping timeout: 246 seconds]
ravi has quit [Quit: Leaving]
gmg has joined #systemtap
gmg has quit [Client Quit]
mbenitez_ has joined #systemtap
mbenitez has quit [Read error: Connection reset by peer]
mbenitez_ is now known as mbenitez
mbenitez has quit [Changing host]
mbenitez has joined #systemtap
hpt has quit [Ping timeout: 260 seconds]
pwithnall____ has quit [Ping timeout: 240 seconds]
orivej has quit [Ping timeout: 240 seconds]
pwithnall____ has joined #systemtap
pwithnall____ has quit [Ping timeout: 240 seconds]
csanting has quit [Ping timeout: 268 seconds]
wcohen has quit [Ping timeout: 245 seconds]
orivej has joined #systemtap
sona has joined #systemtap
wcohen has joined #systemtap
mjw has quit [Quit: Leaving]
csanting has joined #systemtap
sona has quit [Ping timeout: 264 seconds]
brolley has left #systemtap [#systemtap]
csanting has quit [Ping timeout: 240 seconds]
csanting has joined #systemtap
gmg has joined #systemtap
csanting has quit [Read error: Connection reset by peer]
csanting has joined #systemtap
mbenitez has quit [Quit: Leaving]
<serhei>
Bit of a random stap question. I'm running the following script 'global counter = 0; probe process.function("*").call { counter++ }; probe end { printf("%d calls\n", counter) }' using both kernel-mode stap (uprobes) and dyninst
<serhei>
My dyninst run reports 'run completed in 18630usr/760sys/20257real ms.'
<serhei>
while the kernel-mode run finishes in under a second.
<serhei>
(On a moderately sized target program)
<serhei>
Both report the same count (110077), so both are instrumenting the same functions
<serhei>
I'm trying to figure out why uprobes is so much faster in this case -- any thoughts?
<jistone>
serhei, uprobes just drops a breakpoint at each address; dyninst rewrites the instructions inline (often jumping to out-of-line code)
<jistone>
thus dyninst has to do a lot of instruction analysis
tromey has quit [Quit: ERC (IRC client for Emacs 26.0.50)]
<serhei>
Hmm
<serhei>
jistone, thanks for the info!
<jistone>
serhei, while dyninst pays a heavy initial cost, it may be a lot faster when it actually starts running
<jistone>
mainly for not trapping into the kernel
<serhei>
Ok
<serhei>
I would have to find a long-running program to see that in practice, then
<jistone>
yeah
<serhei>
Also, if dyninst does the analysis up-front, it should be possible to separate out the analysis time from the actual program run
<serhei>
& measure just the latter
<jistone>
well, unless new processes are started during the run
<serhei>
True enough
<serhei>
But still handy
<jistone>
dyninst also has a binary rewriter -- might be neat to explore that for stap
<serhei>
Another instrumentation framework I've worked with (DynamoRIO) is binary-rewriting-based and instruments everything on-demand as the basic blocks come up for execution... so it's not possible to evaluate analysis time separately from program execution
<serhei>
Hold on, I'm seeing dyninst's binary rewriter is a bit different than that
<serhei>
They're referring to static ahead-of-time rewriting