On Fri, Mar 11 2016, Marcin KoÅcielnicki wrote:
We could also try to collect 14*<wordsize>(%r11), hoping that's the
save slot for %r14, but the interface unfortunately doesn't support
collecting multiple values (no matter what the comment above says).
Nah, that doesn't help either, since most functions don't use r11 as a
frame pointer. There is just no way to locate the return address unless
we have call frame information or perform code analysis.
Unfortunately, this interface is just not very well-designed - both
x86 and aarch64 just take a shot in the dark like this patch. A
better way would be to reuse the existing unwinders and remove this
hook altogether, or (for while-stepping, where we can't predict the
PC) actually allow multiple values and aim at a few likely locations.
But IMO that's not in scope for this patchset.
The point I was trying to make is that r14 is fairly *unlikely* to
contain the return address, unless we're near function entry. If we
just called a function, then r14 contains an address within our own
function. Otherwise r14 can also contain something else entirely.