fche changed the topic of #systemtap to: http://sourceware.org/systemtap; email systemtap@sourceware.org if answers here not timely, conversations may be logged
<bendlas>
mhh, process.insn tells me `semantic error: process probes not available without kernel CONFIG_UTRACE`, even though process.function works and CONFIG_UTRACE seems to be gone from kernel 4.7
<bendlas>
is there a UPROBE based variant for process.insn
<bendlas>
?
<fche>
bendlas, sorry, no. that facility was not ported into the new uprobes.
<fche>
such probes work only on rhel6 era kernels
<bendlas>
pity
<bendlas>
is somebody working on this?
<bendlas>
or can I use uprobes directly, somehow?
<fche>
uprobes are for probes placed at particular addresses
<fche>
the .insn probes were for single-stepping
<bendlas>
so I'll have to run binaries without debug info in my own debugger?
<bendlas>
what about this dyninst business?
<fche>
ok hold on, you said process.insn last
<fche>
process probes (CONFIG_UPROBES) are indeed in 4.7 era kernels for most architectures
<fche>
that's non-process.insn - just process.function / .statement / that sort of thing
<fche>
ah yes, and that's working for you
<fche>
sorry, it's late here, I keep misreading you :)
<fche>
ok so for .insn single stepping, for real, yeah there seem to be no kernel facilities for that at the moment
<fche>
dyninst - that can -probably- do the job, though I don't think we have a systemtap front-end for that
<fche>
gdb / gdbserver can definitely do the job, but it's a whole different feel/infrastructure
<bendlas>
is dyninst similar to valgrind?
<fche>
kind of sort of - dyninst is a library with an api, whereas valgrind is a full tool
<fche>
you can think of valgrind's internal tools operating against an api that's sort of similar to dyninst's
ananth has joined #systemtap
<bendlas>
so, systemtap can use dyninst as a backend if there is no kernel support, but there are no probe types?
<fche>
there are certainly probe types for stap --runtime=dyninst; specifically function/statement probes
<fche>
just no equivalent for old-school rhel5/5 utrace process.insn single-stepping.
<fche>
chances are systemtap-dyninst could support a process.insn probe point. you could more formally register your interest in that by opening a bug/rfe against systemtap for thsi
<bendlas>
ok, thanks for the info
ananth has quit [Ping timeout: 265 seconds]
ananth has joined #systemtap
irker289 has quit [Quit: transmission timeout]
nkambo has joined #systemtap
ravi_ has joined #systemtap
pwithnall has joined #systemtap
pwithnall has quit [Remote host closed the connection]
ananth has quit [Ping timeout: 250 seconds]
ananth has joined #systemtap
ego_ has joined #systemtap
hkshaw has joined #systemtap
nkambo has quit [Remote host closed the connection]
nkambo has joined #systemtap
zodbot has quit [Quit: Quick restart to free up memory]
zodbot has joined #systemtap
hchiramm has quit [Ping timeout: 250 seconds]
ananth has quit [Ping timeout: 276 seconds]
ton31337 has quit [Ping timeout: 265 seconds]
ananth has joined #systemtap
ton31337 has joined #systemtap
ego_ has quit [Quit: Leaving]
nkambo has quit [Ping timeout: 276 seconds]
nkambo has joined #systemtap
ravi_ has quit [Remote host closed the connection]
hkshaw has quit [Quit: Leaving.]
drsmith has joined #systemtap
wcohen has quit [Ping timeout: 244 seconds]
mbenitez has joined #systemtap
hkshaw has joined #systemtap
tromey has joined #systemtap
irker110 has joined #systemtap
<irker110>
systemtap: mcermak systemtap.git:refs/heads/master * release-3.0-251-ga10bdce / staptree.cxx: Let the @variance pretty printer show the bit_shift if specified. http://tinyurl.com/gpkgws2
wcohen has joined #systemtap
ananth has quit [Ping timeout: 255 seconds]
mbenitez has quit [Quit: To office]
brolley has joined #systemtap
mbenitez has joined #systemtap
hchiramm has joined #systemtap
irker110 has quit [Quit: transmission timeout]
mjw has quit [Quit: Leaving]
nkambo has quit [Ping timeout: 265 seconds]
<jistone>
dyninst process.insn -- just musing that should be *technically* possible, but I shudder to think how that would actually work
<fche>
there may be a ProcessControl API for that
<jistone>
PTRACE_SINGLE_STEP, notifies mutator, mutator rewrite regs to run a callback in the mutatee, PTRACE_CONT, notifies that callback finished, GOTO 10
<fche>
it'd be slow as heck
<jistone>
thus I shudder
<fche>
but ... the only game in town in modern kernel land
<fche>
(and probably still faster than gdb)
<jistone>
OR we could do a massive process rewrite, literally instrumenting our calls after EVERY instruction
<jistone>
that would at least stay in process
<fche>
and take apprx. a year to insert it all? :)
<fche>
well, easy enough to try
<jistone>
I think you'd be much better off with valgrind/pin/etc
<fche>
imagine someone was fond of the systemtap ecosystem
<fche>
don't laugh now, such people exist :-)
<jistone>
we are a hammer, and that's not a nail
<fche>
how much dyninst performance sloth might they be willing to accept to do insn-by-insn tracing of (say) a function?
<fche>
or a module?
<fche>
it'd be nice to have at least a little bit of data to offer the analysis
<jistone>
well, it doesn't hurt to have an RFE
<fche>
yeah. can't promise prompt action.
<jistone>
btw, what is this .insn.block? how does that work?
<fche>
it set another processor status bit to break on branches
<fche>
not on insns
<fche>
dunno if ptrace(2) has an equialent
<jistone>
huh, I didn't know that existed
<jistone>
I don't think that's in ptrace
<fche>
(but anyway it'd be nice to teach stap to interface to branch-record type tracing in the kernel)