fche changed the topic of #systemtap to: http://sourceware.org/systemtap; email systemtap@sourceware.org if answers here not timely, conversations may be logged
<agentzh> is this a known issue?
<agentzh> gdb does not have this issue when setting breakpoints on parent functions' entries.
<agentzh> is there a way to compensate this side effects of uprobes?
<agentzh> *effect
<agentzh> sorry, i mean putting a return probe on main().
<agentzh> the backtrace always stopped at the frame 0x7fffffffe000.
<agentzh> created a PR with a minimal example: https://sourceware.org/bugzilla/show_bug.cgi?id=23876
<agentzh> fche: it would be great if you can have a quick look. thanks!
<fche> function return probes are known to muck with backtraces :(
<agentzh> any workaround to that?
<fche> I don't know of one. the main problem is that when the kernel mucks up the stack (to hook into the retprobes machinery), it doesn't emit info that enables a general unwinder to follow that trampoline back up
<fche> (I wouldn't be surprised if you had a *retprobe on a program, and ran gdb, you'd see the bad effect too.)
_whitelogger has joined #systemtap
<agentzh> fche: will it help if i probe onto the ret instructions myself to emulate the return probes using ordinary uprobes?
<agentzh> thanks for your explanation on the problems with uretprobes + unwinding
<agentzh> for a related question, is there a probe syntax to add a probe onto an arbitrary instruction address? the absolute statement syntax does not work with inode-based uprobes, it seems.
<agentzh> sorry if it's already documented somewhere. just never seen such info.
_whitelogger has joined #systemtap
sscox has quit [Ping timeout: 276 seconds]
sscox has joined #systemtap
sscox has quit [Ping timeout: 240 seconds]
sscox has joined #systemtap
<fche> yes, if you can put a probe onto the ret, you should see workable tracebacks
<fche> t
<fche> the difficulty is in locating them. (dtrace at one point used to disassemble the target binaries to locate ret's.)
<fche> see PR10056, PR18714
<fche> @agentzh ^
<agentzh> fche: great! will check them out.
<agentzh> thanks!
<fche> they're long-unresolved, so yeah just a placeholder for known missing features
<agentzh> got it.
<agentzh> fche: is it possible to specify a probe on an instruction address?
<agentzh> right now in the stap language?
<fche> for userspace? I believe no.
<agentzh> yes, userspace.
<agentzh> the absolute statement syntax does not work with inode-based uprobes, it seems.
<fche> yes, that's the subject of the second PR
<agentzh> oh, sorry, just read the first one, not the 2nd one.
<agentzh> PR18714 is not for fortran? https://gcc.gnu.org/bugzilla/show_bug.cgi?id=18714
<agentzh> *is for
<agentzh> wrong PR number?
<fche> yea
<fche> no
<agentzh> oh sorry, was distracted by the gcc bugzilla link in the first PR
<fche> they're both sourceware.org/bugzilla numbers
<agentzh> *nod*
<agentzh> okay, inode+offset probe is still a TODO.
<agentzh> do you have any syntax in mind?
<fche> process.statement(0xaddr) - the question is whether 0xaddr can be unambiguously interpreted by the user
<agentzh> and also process("file").statement(0xaddr) ?
<fche> or .statement(0xaddr).absolute, which is what the syntax used to be (and referred to run-time vm addresses)
<fche> yes
<agentzh> i think the statement(0xaddr).absolute is still a relative address? vm addresses are volatile for PIE/PIC.
<fche> it -wasn't- relative, that was the point of the .absolute suffix
<agentzh> okay, then i had the wrong memory.
<fche> statement(0xaddr) alone would refer to a location similarly as .statement("*@file.c:444") would
<agentzh> okay
<agentzh> we'll take a stab at implementing it.
<agentzh> for inode-based uprobes.
<agentzh> it would also complete the gap for true dwarf-less probling :)
<agentzh> with @vma() under the belt already.
<fche> sure
<fche> would suggest thinking of the first PR (non retprobes for return probes) as separate from the second PR (inode-address)
<agentzh> sure, they're different.
<agentzh> is there any dwarf marker for ret instructions yet?
<agentzh> there's no pointers in PR49167
<agentzh> beside the one for tailcalls.
<fche> not really good ones, as at that time. an 'epilogue' tag exists
<fche> and could be that alex oliva's recent sfn-related debuginfo improvements in gcc give enough info
<fche> but someone would have to dig in and see
<agentzh> okay, i'm taking notes.
<agentzh> thanks
<fche> righto
<agentzh> it would be much easier if we don't have to analyze the full function instructions.
<fche> of course
<fche> that's why stap isn't doing that
<fche> plus we're pretty cross-platform
<agentzh> aye
gila has joined #systemtap
<agentzh> fche: hmm, seems like process.statement(0xaddr) is already working with inode-based uprobes?
<agentzh> just tried this: stap -e 'probe process.statement(0x4004b6) { println(register("eax")) }' -c ./a.out
<agentzh> and it seems to work alright.
<agentzh> the only annoying bit is this error: "semantic error: address 0x4004b7 does not match the beginning of a statement (try 0x4004b6)"
<agentzh> maybe we can relax this a bit by something like a command-line option?
<fche> that'd be dwarf based, searching the line / pc-range mapping tables
<agentzh> oh, i see.
orivej_ has quit [Ping timeout: 246 seconds]
<ggherdov> Hello, I'm getting this error from a tapset at Pass 5: "ERROR: module release mismatch (4.18.0-MY-KERNEL-FOO vs 4.18.0-MY-KERNEL-BAR)"
<ggherdov> Indeed I just compiled and installed these two kernel version, but I'm not sure which "module" is systemtap complaining about. Full error at https://bpaste.net/show/741a3868e4b5
<ggherdov> Any hint on how to fix that?
<fche> So the version of the kernel build tree stap's using must be for the wrong one - not the kernel that you're actually running
<ggherdov> oh, I see.
<fche> if you bump up the verbosity two more levels (another -vv), stap will rat out where the kernel build tree it's using: