Messages in this thread | | | Date | Tue, 1 Dec 2015 09:38:45 +0100 | From | Peter Zijlstra <> | Subject | Re: [BUG REPORT] perf tools: x86_64: Broken calllchain when sampling taken at 'callq' instruction |
| |
On Tue, Dec 01, 2015 at 08:28:26AM +0100, Ingo Molnar wrote: > > Not sure what you're getting at here. We don't need the uncorrected > > instruction. > > Well, we need it for stack unwinding, as you point it out: > > > But the problem here is that we rewind the instruction stream, but not > > the stack. And the stack unwinder is (obviously) interested in the stack > > state. > > Unwinding the stack state would fix it as well - but an equivalent solution would > be to pass along the original RIP would fix it as well: we'd have a > self-consistent pair of RIP/RSP. > > Especially since unwinding the RSP is probably hard: > > > I'm not sure we want (or need) to go undo the specific instruction's > > stack effect in-kernel. If the !DWARF unwinders are similarly confused > > we might need to put it in kernel (expensive *groan*). If its only the > > DWARF muck then its something that can be done in userspace just > > fine, although we might need to copy slightly more of the stack than SP > > is pointing at, such that we can undo RET/POP etc. which would have data > > beyond the head of stack. > > > > The easiest solution might be to figure out the biggest stack offset for > > any instruction and always capture that much over the head of stack. > > so I think the problem here is that the RSP does not match up to the RIP. We can > either pass along the original RIP+RSP, or the fixed up one - but what we do > currently is that we pass along only half of it - which corrupts dwarf unwinding > state that doesn't tolerate such errors.
Still not sure what that gets you. Then you get a sample at a known wrong location, why would you want that?
| |