From: Yao Qi <qiyaoltc@gmail.com>
To: Alan Hayward <Alan.Hayward@arm.com>
Cc: "gdb-patches\@sourceware.org" <gdb-patches@sourceware.org>,
Subject: Re: [PATCH 3/11] Add MIPS_MAX_REGISTER_SIZE
Date: Tue, 11 Apr 2017 15:37:00 -0000 [thread overview]
Message-ID: <86y3v7uf9j.fsf@gmail.com> (raw)
In-Reply-To: <3C00280E-37C9-4C0A-9DA6-F3B9DB1A6E8F@arm.com> (Alan Hayward's message of "Tue, 4 Apr 2017 10:12:39 +0000")
Alan Hayward <Alan.Hayward@arm.com> writes:
Hi Alan,
There are different ways of getting rid of MAX_REGISTER_SIZE, let us try
some simple approaches first. Some uses of MAX_REGISTER_SIZE still
can't be removed, but let us start from easy part.
> diff --git a/gdb/mips-linux-tdep.c b/gdb/mips-linux-tdep.c
> index 57e75b5343e1b927e9fe28dea16759f769cf4506..ce2f378854f4b66c426fd9d6683831e8795c58a6 100644
> --- a/gdb/mips-linux-tdep.c
> +++ b/gdb/mips-linux-tdep.c
> @@ -118,7 +118,7 @@ supply_32bit_reg (struct regcache *regcache, int regnum, const void *addr)
> {
> struct gdbarch *gdbarch = get_regcache_arch (regcache);
> enum bfd_endian byte_order = gdbarch_byte_order (gdbarch);
> - gdb_byte buf[MAX_REGISTER_SIZE];
> + gdb_byte buf[MIPS_MAX_REGISTER_SIZE];
Given the function name supply_32bit_reg, all registers are 32-bit here,
so we can do "buf[4]"?
> @@ -470,7 +470,7 @@ mips64_fill_gregset (const struct regcache *regcache,
>
> if (regaddr != -1)
> {
> - gdb_byte buf[MAX_REGISTER_SIZE];
> + gdb_byte buf[MIPS_MAX_REGISTER_SIZE];
> LONGEST val;
>
> regcache_raw_collect (regcache, regno, buf);
The "buf" is used by regcache_raw_collect + extract_signed_integer,
regcache_raw_collect (regcache, regno, buf);
val = extract_signed_integer (buf, register_size (gdbarch, regno),
byte_order);
this pattern exists in some places, so can we add a new regcache api,
LONGEST
regcache_raw_collect_signed (const struct regcache *regcache, int regnum)
{
struct gdbarch *gdbarch = get_regcache_arch (regcache);
enum bfd_endian byte_order = gdbarch_byte_order (gdbarch);
return extract_signed_integer (register_buffer (regcache, regnum),
register_size (gdbarch, regnum),
byte_order);
}
this will remove one memory copy, as well as the local buffer "buf".
> diff --git a/gdb/mips-tdep.c b/gdb/mips-tdep.c
> index 41cb9d82c6ef473c1fbbf86601914f9a4f462411..51a22ba29a520639bdeb95c235c00c74ad40435b 100644
> --- a/gdb/mips-tdep.c
> +++ b/gdb/mips-tdep.c
> @@ -4527,7 +4527,7 @@ mips_eabi_push_dummy_call (struct gdbarch *gdbarch, struct value *function,
> for (argnum = 0; argnum < nargs; argnum++)
> {
> const gdb_byte *val;
> - gdb_byte valbuf[MAX_REGISTER_SIZE];
> + gdb_byte valbuf[MIPS_MAX_REGISTER_SIZE];
> struct value *arg = args[argnum];
> struct type *arg_type = check_typedef (value_type (arg));
> int len = TYPE_LENGTH (arg_type);
> @@ -5758,7 +5758,7 @@ mips_o32_return_value (struct gdbarch *gdbarch, struct value *function,
> /* A struct that contains one or two floats. Each value is part
> in the least significant part of their floating point
> register.. */
> - gdb_byte reg[MAX_REGISTER_SIZE];
> + gdb_byte reg[MIPS_MAX_REGISTER_SIZE];
"reg" is not used at all, we can remove it.
> int regnum;
> int field;
> for (field = 0, regnum = mips_regnum (gdbarch)->fp0;
> @@ -6473,7 +6473,7 @@ print_gp_register_row (struct ui_file *file, struct frame_info *frame,
> {
> struct gdbarch *gdbarch = get_frame_arch (frame);
> /* Do values for GP (int) regs. */
> - gdb_byte raw_buffer[MAX_REGISTER_SIZE];
> + gdb_byte raw_buffer[MIPS_MAX_REGISTER_SIZE];
> int ncols = (mips_abi_regsize (gdbarch) == 8 ? 4 : 8); /* display cols
> per row. */
"raw_buffer" is used in deprecated_frame_register_read, so can we use
get_frame_register_value instead? so that "raw_buffer" is not needed.
--
Yao (齐尧)
next prev parent reply other threads:[~2017-04-11 15:37 UTC|newest]
Thread overview: 44+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-04-04 10:12 Alan Hayward
2017-04-04 17:19 ` John Baldwin
2017-04-05 10:27 ` Alan Hayward
2017-04-11 15:37 ` Yao Qi [this message]
2017-05-05 8:03 ` [PATCH 3/11] Add MIPS_MAX_REGISTER_SIZE (1/4) Alan Hayward
2017-05-05 21:44 ` Yao Qi
2017-05-05 8:04 ` [PATCH 3/11] Add MIPS_MAX_REGISTER_SIZE (4/4) Alan Hayward
2017-06-07 8:31 ` Alan Hayward
2017-06-08 20:27 ` Maciej W. Rozycki
2017-06-09 10:31 ` Alan Hayward
2017-06-09 11:03 ` Pedro Alves
2017-06-09 11:48 ` Maciej W. Rozycki
2017-06-09 12:05 ` Pedro Alves
2017-06-09 13:23 ` Maciej W. Rozycki
2017-06-09 14:29 ` Pedro Alves
2017-06-12 9:09 ` Alan Hayward
2017-06-12 18:11 ` Pedro Alves
2017-06-12 14:29 ` Maciej W. Rozycki
2017-05-05 8:04 ` [PATCH 3/11] Add MIPS_MAX_REGISTER_SIZE (2/4) Alan Hayward
2017-05-05 19:51 ` John Baldwin
2017-05-12 8:53 ` Yao Qi
2017-05-16 11:16 ` Alan Hayward
2017-05-22 12:07 ` Yao Qi
2017-05-22 16:05 ` Alan Hayward
2017-05-22 17:15 ` Pedro Alves
2017-05-23 17:49 ` Alan Hayward
2017-05-23 18:30 ` Pedro Alves
2017-05-24 9:08 ` Alan Hayward
2017-05-24 9:20 ` Pedro Alves
2017-05-24 10:20 ` Alan Hayward
2017-05-24 11:07 ` Pedro Alves
2017-05-24 19:45 ` Alan Hayward
2017-05-25 10:46 ` Pedro Alves
2017-05-25 11:43 ` Yao Qi
2017-05-25 11:48 ` Pedro Alves
2017-05-26 8:54 ` Alan Hayward
2017-05-26 10:26 ` Pedro Alves
2017-05-26 15:30 ` Alan Hayward
2017-05-26 15:49 ` Pedro Alves
2017-05-26 16:18 ` Alan Hayward
2017-05-26 16:00 ` John Baldwin
2017-05-24 9:29 ` Pedro Alves
2017-05-05 8:04 ` [PATCH 3/11] Add MIPS_MAX_REGISTER_SIZE (3/4) Alan Hayward
2017-05-05 21:54 ` Yao Qi
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=86y3v7uf9j.fsf@gmail.com \
--to=qiyaoltc@gmail.com \
--cc=Alan.Hayward@arm.com \
--cc=gdb-patches@sourceware.org \
/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).