public inbox for gdb-patches@sourceware.org
 help / color / mirror / Atom feed
From: John Baldwin <jhb@FreeBSD.org>
To: Simon Marchi <simon.marchi@polymtl.ca>, gdb-patches@sourceware.org
Cc: Ulrich Weigand <uweigand@de.ibm.com>, Tom Tromey <tom@tromey.com>,
	Simon Marchi <simon.marchi@ericsson.com>
Subject: Re: [PATCH v2 1/3] Extract register_reader and register_readwriter interfaces from regcache
Date: Fri, 08 Feb 2019 16:47:00 -0000	[thread overview]
Message-ID: <bcd04275-5fa6-cdec-0532-68e4daac03be@FreeBSD.org> (raw)
In-Reply-To: <20181024014333.14143-2-simon.marchi@polymtl.ca>

On 10/23/18 6:43 PM, Simon Marchi wrote:
> From: Simon Marchi <simon.marchi@ericsson.com>
> 
> In the following patch, we make gdbarch pseudo-registers hooks read and
> write required registers from a frame instead of from the current
> regcache.  To avoid having to change the implementation of all
> architectures to use a different interface, we can re-use the regcache
> interface.
> 
> This patch extracts two interfaces, register_reader and
> register_readwriter, and make respectively readable_regcache and
> regcache inherit from them.  register_reader is "something from which
> you can read register values from".  It can of course be a regcache, but
> it will also be (in the following patch) something that unwinds
> registers for a particular frame.  As you would expect,
> register_readwriter is "something you can read and write registers
> from/to".
> 
> Some notes about the implementation.  This results in diamond
> inheritance: regcache inherits from both readable_regcache and
> register_readwriter, which both inherit from register_reader.  It is
> therefore necessary to use virtual inheritance (use "public virtual"),
> otherwises we end up with errors like:
> 
>   /home/emaisin/src/binutils-gdb/gdb/regcache.c:210:20: error: request
>   for member ‘cooked_read’ is ambiguous
> 
> Also, the raw_read method in readable_regcache hides the raw_read
> template method in register_reader.  So it's necessary to use "using
> register_reader::raw_read" so that clients of readable_regcache are able
> to call register_reader's raw_read.  Same thing for some cooked_read,
> raw_write and cooked_write.
> 
> All corresponding gdbarch hooks are updated to use register_reader or
> register_readwriter instead of readable_regcache and regcache, but
> otherwise they are not changed.
> 
> With this patch, no behavior change is expected.
> 
> @@ -539,20 +541,19 @@ regcache_raw_read_signed (struct regcache *regcache, int regnum, LONGEST *val)
>  
>  template<typename T, typename>
>  enum register_status
> -readable_regcache::raw_read (int regnum, T *val)
> +register_reader::raw_read (int regnum, T *val)
>  {
> -  gdb_byte *buf;
> -  enum register_status status;
> +  gdbarch *arch = this->arch ();
> +  int reg_size = register_size (arch, regnum);
> +  gdb_byte buf[reg_size];
> +
> +  register_status status = raw_read (regnum, buf);
>  
> -  assert_regnum (regnum);
> -  buf = (gdb_byte *) alloca (m_descr->sizeof_register[regnum]);
> -  status = raw_read (regnum, buf);

This "loses" the assert_regnum().  Is that replaced for regcache's by the
gdb_assert() you added in readable_regcache::raw_read()?  Did you consider
moving that assertion to here instead so it would also be enforced in the
frame version of register_reader?  (Or does the frame version also add its
own assertion in the following patches?)

Similar question about register_readwriter::raw_write,
register_reader::cooked_read, and register_readerwriter::cooked_write.

The only other general comment is that while I appreciate that this doesn't
require changing the tdep files very much (which is a good thing), it does
have the odd result that the variable names in the gdbarch methods are still
named 'regcache' even though they aren't regcache's anymore.  It's perhaps
not worth it, but it might be nice to do a followup pass eventually to
rename 'register_reader *regcache' to 'reader' and something similar for
the writer case?  It seems tedious though, and I don't think it should be a 
requirement/blocker, just a suggestion for the future perhaps.

-- 
John Baldwin

                                                                            

  reply	other threads:[~2019-02-08 16:47 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-10-24  1:43 [PATCH v2 0/3] Read pseudo registers from frame instead of regcache Simon Marchi
2018-10-24  1:43 ` [PATCH v2 3/3] Add tests for unwinding of pseudo registers Simon Marchi
2018-10-24  1:43 ` [PATCH v2 2/3] Read pseudo registers from frame instead of regcache Simon Marchi
2019-02-08 16:53   ` John Baldwin
2018-10-24  1:43 ` [PATCH v2 1/3] Extract register_reader and register_readwriter interfaces from regcache Simon Marchi
2019-02-08 16:47   ` John Baldwin [this message]
2019-02-09  5:24     ` Simon Marchi
2019-02-08 13:47 ` [PATCH v2 0/3] Read pseudo registers from frame instead of regcache Simon Marchi
2019-02-11 16:56 ` 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=bcd04275-5fa6-cdec-0532-68e4daac03be@FreeBSD.org \
    --to=jhb@freebsd.org \
    --cc=gdb-patches@sourceware.org \
    --cc=simon.marchi@ericsson.com \
    --cc=simon.marchi@polymtl.ca \
    --cc=tom@tromey.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).