[PATCH 4/8] gdb/s390: Fill gen_return_address hook.
Marcin Kościelnicki
koriakin@0x04.net
Fri Mar 11 12:26:00 GMT 2016
On 11/03/16 13:18, Andreas Arnez wrote:
> 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.
Well, it works for leaf functions... not much, but not totally useless
either.
>
> Is there a way to admit that we don't know the return address? What if
> we always return garbage? E.g., maybe it's better to always return 0?
>
We can always error() in there (and KFAIL the testcase in gdb.trace that
exercises it). However, returning garbage here doesn't result in
garbage backtrace - this only collects data, if the unwinder actually
doing the work later determines it should look for the return address on
the stack, it'll just ignore our collected $r14 and consider the return
address unavailable (unless another collect rule happened to match it).
More information about the Gdb-patches
mailing list