public inbox for gdb-patches@sourceware.org
 help / color / mirror / Atom feed
From: "Ulrich Weigand" <uweigand@de.ibm.com>
To: simon.marchi@polymtl.ca (Simon Marchi)
Cc: gdb-patches@sourceware.org, simon.marchi@ericsson.com (Simon Marchi)
Subject: Re: [RFC PATCH] Read pseudo registers from frame instead of regcache
Date: Mon, 28 May 2018 19:13:00 -0000	[thread overview]
Message-ID: <20180528174715.A954AD804AD@oc3748833570.ibm.com> (raw)
In-Reply-To: <20180526002406.18166-1-simon.marchi@polymtl.ca> from "Simon Marchi" at May 25, 2018 08:24:06 PM

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.

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.)

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 ...

Bye,
Ulrich

-- 
  Dr. Ulrich Weigand
  GNU/Linux compilers and toolchain
  Ulrich.Weigand@de.ibm.com

  parent reply	other threads:[~2018-05-28 17:47 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 [this message]
2018-05-28 22:06   ` Simon Marchi
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=20180528174715.A954AD804AD@oc3748833570.ibm.com \
    --to=uweigand@de.ibm.com \
    --cc=gdb-patches@sourceware.org \
    --cc=simon.marchi@ericsson.com \
    --cc=simon.marchi@polymtl.ca \
    /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).