From: Simon Marchi <simon.marchi@polymtl.ca>
To: Ulrich Weigand <uweigand@de.ibm.com>
Cc: gdb-patches@sourceware.org, simon.marchi@ericsson.com
Subject: Re: [RFC PATCH] Read pseudo registers from frame instead of regcache
Date: Mon, 28 May 2018 22:06:00 -0000 [thread overview]
Message-ID: <13ad2ec8a2cd7b6393613e4728d70736@polymtl.ca> (raw)
In-Reply-To: <20180528174715.A954AD804AD@oc3748833570.ibm.com>
Hi Ulrich,
Thanks for the feedback.
On 2018-05-28 13:47, Ulrich Weigand wrote:
> Simon Marchi wrote:
>
>> The problem: Reading pseudo registers from an upper stack frame does
>> not
>> work. The raw registers needed to compose the pseudo registers are
>> always read from the current thread's regcache, which is effectively
>> frame #0's registers.
>
> I think this may have been by design at some point. The idea being:
> for the innermost frame, you construct your register set using the
> ptrace
> (or whatever) interface, possibly using arch-specific constructions
> (the "pseudo" registers). But for higher frames, you construct *all*
> registers directly via the unwinding logic.
That make sense, I don't think my patch really changes that. What my
patch changes is that we can reconstruct pseudo register values from
unwound raw register values, which we couldn't before. In the simple
rbx/ebx case I tried, next_frame will never have info about ebx (trying
to use it in cfi_offset gives "bad register expression"), so it doesn't
make sense to query it about the location of ebx.
> For example, on a platform where a floating-point register was extended
> to a vector register at some point, your ptrace interface may be split
> between the original FP part, and the "remaining" piece, so to
> construct
> the full vector register, you'd have to make two ptrace requests and
> combine them (using a "pseudo" register). But if you want to find the
> value of the vector register in a higher frame, there will be unwind
> info for the full vector register, and not the two pieces.
>
> (This construct actually exists on Intel as well, e.g. with the ymmh
> register parts. However, since ymm is not call-saved in the Linux ABI,
> we don't have unwind info either way ... In some other ABI, this could
> be an actual problem, however.)
Ok, I was assuming that it was never possible for the debug info to
describe how pseudo registers are saved, only raw registers. Do you
have an architecture in mind where it's possible to have a pseudo
register mentioned in the unwind information? GNU as doesn't accept at
all "ymm0" or "ymm0h" as an argument to .cfi_offset, so I don't know how
ymm0 would be represented if we wanted to save it (despite it not being
callee saved according to the ABI).
If the unwind info can indeed contain explicit information about pseudo
registers (and therefore implicit info about the raw registers that
compose it), can't it lead to very difficult situations? There is
normally only one way to reconstruct a pseudo register value from raw
registers. But a raw register can be part of many pseudo registers. So
if we need to unwind a raw register value for which the next frame has
no explicit information, then we need to check if it has info about all
the possible pseudo registers this raw register is part of?
> So this change:
>
>> - /* Ask this frame to unwind its register. */
>> - value = frame->unwind->prev_register (frame,
>> &frame->prologue_cache, regnum);
>> + struct value *value;
>> + if (regnum < gdbarch_num_regs (gdbarch))
>> + {
>> + /* This is a raw register, we can directly ask the next frame
>> to unwind
>> + the register. */
>> + value = next_frame->unwind->prev_register (next_frame,
>> + &next_frame->prologue_cache,
>> + regnum);
>> + }
>> + else if (gdbarch_pseudo_register_read_value_p (gdbarch))
>> + {
>> + /* This is a pseudo register, we don't know how how what raw
>> registers
>> + this pseudo register is made of. Ask the gdbarch to read
>> the value,
>> + it will itself ask the next frame to unwind the values of
>> the raw
>> + registers it needs to compose the value of the pseudo
>> register. */
>> + value = gdbarch_pseudo_register_read_value (gdbarch,
>> next_frame, regnum);
>> + }
>
> in effect changes what unwind info GDB expects. Now maybe it is still
> the
> correct change, but this at least needs a review on how pseudo register
> unwind info is currently handled across all architectures ...
I'll do what I can, but don't expect me to be an expert of all CPU
architectures anytime soon :).
Simon
next prev parent reply other threads:[~2018-05-28 19:13 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-05-26 1:14 Simon Marchi
2018-05-27 5:14 ` Tom Tromey
2018-05-28 16:10 ` Simon Marchi
2018-05-28 19:13 ` Ulrich Weigand
2018-05-28 22:06 ` Simon Marchi [this message]
2018-05-29 2:52 ` Simon Marchi
2018-05-29 14:53 ` Ulrich Weigand
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=13ad2ec8a2cd7b6393613e4728d70736@polymtl.ca \
--to=simon.marchi@polymtl.ca \
--cc=gdb-patches@sourceware.org \
--cc=simon.marchi@ericsson.com \
--cc=uweigand@de.ibm.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).