On Thu, Apr 20, 2017 at 10:44 AM, evgeny777 <evgeny.levi...@gmail.com> wrote:
> I noticed that GetPreviousInstructionPc() function returns 'pc - 1' for both
> arm32 and arm64.
> This causes odd addresses to appear in stack traces, which is nonsense, as
> both arm32/64 instructions
> have 4 byte size and alignment.
> The x86 and x86_64 cases are even more confusing, because instruction length
> is not constant. What exactly this 'pc - 1' is expected to return?
> But even if one is able to get previous instruction address correctly he may
> still get confusing results. In case some instruction triggers
> hardware exception, its address will go to ASAN stack trace (via
> SlowUnwindStackWithContext). Returning address of previous instruction
> in such case can be extremely confusing.
> Is there any point in using this function?
Yes, there is a very bold point in using this function.
Typically top frame PC is obtained with __builtin_return_address,
which means that it points to the next instruction after the call. And
we need to obtain debug info associated with the call instruction. To
achieve that we subtract 1 from PC. All symbolization code that we've
seen is fine with PC pointing into a middle of an instruction.
Now, if we print pc-1 in reports (do we?), then it's a bug. We need to
print unaltered PC in reports.
Re hardware exceptions. This needs to be fixed. A trivial change would
be to add 1 to PCs pointing to faulting instruction. Then
GetPreviousInstructionPc will offset this and we get correct debug
info. However, then we will print incorrect PC in report. So a proper
fix would be to augment all stack traces with a flag saying if top PC
needs to be adjusted during symbolization or not.
You received this message because you are subscribed to the Google Groups
To unsubscribe from this group and stop receiving emails from it, send an email
For more options, visit https://groups.google.com/d/optout.