fche changed the topic of #systemtap to: http://sourceware.org/systemtap; email systemtap@sourceware.org if answers here not timely, conversations may be logged
scox has joined #systemtap
wcohen has quit [Ping timeout: 240 seconds]
hpt has joined #systemtap
wcohen has joined #systemtap
gmg has quit [Remote host closed the connection]
<irker817> systemtap: rth systemtap.git:refs/heads/master * release-3.1-68-g3414d59 / : Revert all bpf patches http://tinyurl.com/kqbya7k
<fche> not for long!
hkshaw has joined #systemtap
hkshaw has left #systemtap [#systemtap]
hkshaw has joined #systemtap
nkambo__ has joined #systemtap
nkambo_ has quit [Ping timeout: 240 seconds]
nkambo_ has joined #systemtap
nkambo__ has quit [Ping timeout: 240 seconds]
ravi has joined #systemtap
sanoj has joined #systemtap
gmg has joined #systemtap
sanoj has quit [Ping timeout: 240 seconds]
sanoj has joined #systemtap
irker817 has quit [Quit: transmission timeout]
gmg has quit [Quit: Leaving.]
sona has joined #systemtap
mjw has joined #systemtap
pwithnall__ has joined #systemtap
sanoj has quit [Ping timeout: 240 seconds]
pwithnall__ has quit [Quit: pwithnall__]
sanoj has joined #systemtap
pwithnall____ has joined #systemtap
lorddoskias has joined #systemtap
<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 ?
hpt has quit [Quit: Lost terminal]
<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
<serhei> Anyways, thanks for the clarification
<fche> jistone, any idea whether dyninst could/would ever want to cache its analysis results?
<jistone> dyninst does cache it in-process, just not persisted. I suppose you could serialize this
<jistone> fche, so... "could": sure; "would": maybe? but probably non-trival
<jistone> (harder than spelling "trivial", at least)
<fche> have you heard it brought up in dyninst land?
<serhei> My impression is that process.function("*") is a bit outside the dyninst use case as originally conceived
pwithnall__ has joined #systemtap
pwithnall__ has quit [Quit: pwithnall__]