This is the mail archive of the
gdb-patches@sourceware.org
mailing list for the GDB project.
Re: [PATCH 4/8] gdb/s390: Fill gen_return_address hook.
- From: Andreas Arnez <arnez at linux dot vnet dot ibm dot com>
- To: Marcin KoÅcielnicki <koriakin at 0x04 dot net>
- Cc: gdb-patches at sourceware dot org
- Date: Fri, 11 Mar 2016 13:18:24 +0100
- Subject: Re: [PATCH 4/8] gdb/s390: Fill gen_return_address hook.
- Authentication-results: sourceware.org; auth=none
- References: <1453637529-26972-5-git-send-email-koriakin at 0x04 dot net> <1454853751-18455-1-git-send-email-koriakin at 0x04 dot net> <m3bn6lz2fu dot fsf at oc1027705133 dot ibm dot com> <56E2AD82 dot 3060101 at 0x04 dot net>
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.
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?
--
Andreas