public inbox for gdb-patches@sourceware.org
 help / color / mirror / Atom feed
From: Yao Qi <qiyaoltc@gmail.com>
To: Alan Hayward <Alan.Hayward@arm.com>
Cc: Pedro Alves <palves@redhat.com>,
	Joel Brobecker <brobecker@adacore.com>,
	"gdb-patches@sourceware.org" <gdb-patches@sourceware.org>,
	nd <nd@arm.com>
Subject: Re: [PATCH] Removal of uses of MAX_REGISTER_SIZE
Date: Fri, 03 Feb 2017 16:50:00 -0000	[thread overview]
Message-ID: <20170203165022.GB11916@E107787-LIN> (raw)
In-Reply-To: <0C6A0D51-4C49-4400-8C46-E77DD512DF56@arm.com>

On 17-02-03 11:25:43, Alan Hayward wrote:
> If someone can ok the common patch, then I’ll make a second patch with the
> replacement of all remaining uses of MAX_REGISTER_SIZE in common code.

I'd like to do it in an iterative way, start from some simple places, like
arm, aarch64, and i386, in which you don't need to define new macros.  Then,
move to some *-tdep.c and *-nat.c, define ${ARCH}_MAX_REGISTER_SIZE when
necessary.  Finally, figure out how to remove MAX_REGISTER_SIZE from
arch-independent code.

> Ensuring it’s not used in common code will allow me to continue moving with the
> aarch64 SVE code.
> 
> 
> There are quite a lot of arch specific functions where we have a register number
> from which the register size could be extracted.  Eg:
> 
> void
> SOMEARCH_pseudo_register_write (struct gdbarch *gdbarch, struct regcache *regcache,
> 			    int regnum, const gdb_byte *buf)
> {
>   gdb_byte raw_buf[MAX_REGISTER_SIZE];
> 
> 
> This could become:
> 
> void
> SOMEARCH_pseudo_register_write (struct gdbarch *gdbarch, struct regcache *regcache,
> 			    int regnum, const gdb_byte *buf)
> {
>   gdb_byte buf[SOMEARCH_MAX_REGISTER_SIZE];
> 
> 
> Or:
> 
> void
> SOMEARCH_pseudo_register_write (struct gdbarch *gdbarch, struct regcache *regcache,
> 			    int regnum, const gdb_byte *buf)
> {
>   std::vector<gdb_byte> buf (register_size (gdbarch, regnum));
> 
> 
> I suspect people will want the first approach? It will result in quite a few new
> defines - ALPHA_MAX_REGISTER_SIZE, PPC_MAX_REGISTER_SIZE etc etc.
> 

That is fine, we've already had I386_MAX_REGISTER_SIZE and M68K_MAX_REGISTER_SIZE.
However, I think that we only have to add these macros when necessary.


-- 
Yao (齐尧)

  reply	other threads:[~2017-02-03 16:50 UTC|newest]

Thread overview: 28+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-01-24 10:31 Alan Hayward
2017-01-27 11:49 ` Pedro Alves
2017-01-27 12:11 ` Pedro Alves
2017-01-27 16:46   ` Alan Hayward
2017-02-01 15:49     ` Pedro Alves
2017-02-01 12:45   ` Yao Qi
2017-02-01 15:48     ` Pedro Alves
2017-02-02  9:40       ` Joel Brobecker
2017-02-03  9:59         ` Alan Hayward
2017-02-03 10:28           ` Yao Qi
2017-02-03 11:00             ` Pedro Alves
2017-02-03 11:25               ` Alan Hayward
2017-02-03 16:50                 ` Yao Qi [this message]
2017-02-06  9:33                   ` Alan Hayward
     [not found]                     ` <20170206152635.GE11916@E107787-LIN>
2017-02-07 16:33                       ` Alan Hayward
2017-02-08 10:47                         ` Yao Qi
2017-02-08 14:17                           ` Alan Hayward
2017-02-08 12:06                         ` Yao Qi
2017-02-08 12:24                         ` Yao Qi
2017-02-08 14:44                           ` Alan Hayward
2017-02-18 23:19                             ` Yao Qi
2017-02-20 11:19                               ` Alan Hayward
2017-02-08 15:32                         ` Yao Qi
2017-02-08 17:10                         ` Yao Qi
2017-02-09 13:26                           ` Alan Hayward
2017-02-14 11:24                           ` Alan Hayward
2017-02-08 17:36                         ` Yao Qi
2017-02-13 11:59                           ` Alan Hayward

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=20170203165022.GB11916@E107787-LIN \
    --to=qiyaoltc@gmail.com \
    --cc=Alan.Hayward@arm.com \
    --cc=brobecker@adacore.com \
    --cc=gdb-patches@sourceware.org \
    --cc=nd@arm.com \
    --cc=palves@redhat.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).