From: John Darrington <john@darrington.wattle.id.au>
To: Kevin Buettner <kevinb@redhat.com>
Cc: gdb-patches@sourceware.org,
John Darrington <john@darrington.wattle.id.au>
Subject: Re: [PATCH 2/2] GDB: S12Z: new function s12z_extract_return_value
Date: Sun, 18 Nov 2018 09:13:00 -0000 [thread overview]
Message-ID: <20181118091337.tqzu3rhmaeyxw7zp@jocasta.intra> (raw)
In-Reply-To: <20181117233550.09353eeb@pinnacle.lan>
Hi Kevin,
Thanks for the review.
On Sat, Nov 17, 2018 at 11:35:50PM -0700, Kevin Buettner wrote:
>
> gdb/ChangeLog:
> * s12z-tdep.c (s12z_extract_return_value): New function.
> (inv_reg_perm) New array.
> (s12z_return_value): Populate readbuf if non-null.
Make sure that this is indented correctly when it eventually goes
in the ChangeLog file.
Is it documented anywhere what "correctly" means?
My two cents on all of the above...
I think you'll have a lot less grief with this architecture port if
you don't try to use the numbering defined in include/opcode/s12z.h.
Create a new numbering with new constants for GDB's purposes ordered
as shown in the reg_perm array. Then use these constants in place of
the various REG_ constants that are currently in s12z-tdep.c. If you
still want to be able to access registers[], it may make sense to
have an array which maps GDB's constants to those in include/opcode.
I'm beginning to think that you're right here. I may change it in the
way you propose in a future patch.
Also, if you want CCH and CCL to be show in "info registers" and/or
allow the user to display and set them, these can be implemented via
the use of pseudo-registers.
A the moment, I don't think it's worth bothering about. CCH and CCL are
merely the high and low bytes of a 16bit register CCW. The names CCH
and CCL only exist because of two (rarely used) instructions in the ISA.
> /* Return the name of the register REGNUM. */
> static const char *
> @@ -467,11 +479,59 @@ s12z_print_registers_info (struct gdbarch *gdbarch,
>
> \f
>
> +
> +static void
> +s12z_extract_return_value (struct type *type, struct regcache *regcache,
> + void *valbuf)
> +{
> + int reg = -1;
> +
> + gdb_byte buf[4];
> +
> + switch (TYPE_LENGTH (type))
> + {
> + case 0: /* Nothing to do */
> + return;
> +
> + case 1:
> + reg = REG_D0;
> + break;
> +
> + case 2:
> + reg = REG_D2;
> + break;
> +
> + case 3:
> + reg = REG_X;
> + break;
> +
> + case 4:
> + reg = REG_D6;
> + break;
> +
> + default:
> + error (_("bad size for return value"));
> + return;
> + }
> +
> + regcache->cooked_read (inv_reg_perm[reg], buf);
> + memcpy (valbuf, buf, TYPE_LENGTH (type));
Is there any reason not to just pass valbuf in place of buf to
cooked_read? Doing so will get rid of the memcpy.
Probably not. Thanks for noticing this.
J'
--
Avoid eavesdropping. Send strong encrypted email.
PGP Public key ID: 1024D/2DE827B3
fingerprint = 8797 A26D 0854 2EAB 0285 A290 8A67 719C 2DE8 27B3
See http://sks-keyservers.net or any PGP keyserver for public key.
next prev parent reply other threads:[~2018-11-18 9:13 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-11-12 9:18 [PATCH 1/2] GDB: S12Z: Add assertion John Darrington
2018-11-12 9:18 ` [PATCH 2/2] GDB: S12Z: new function s12z_extract_return_value John Darrington
2018-11-18 6:35 ` Kevin Buettner
2018-11-18 9:13 ` John Darrington [this message]
2018-11-18 18:28 ` Kevin Buettner
2018-11-20 7:56 ` [PATCH] " John Darrington
2018-11-20 16:40 ` Kevin Buettner
2018-11-20 17:01 ` John Darrington
2018-11-17 21:59 ` [PATCH 1/2] GDB: S12Z: Add assertion Kevin Buettner
2018-11-18 9:23 ` John Darrington
2018-11-18 18:42 ` Kevin Buettner
2018-11-19 16:09 ` Joel Brobecker
2018-11-19 16:47 ` [PATCH] " John Darrington
2018-11-20 5:16 ` Kevin Buettner
2018-11-15 19:02 [PATCH 2/2] GDB: S12Z: new function s12z_extract_return_value John Darrington
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=20181118091337.tqzu3rhmaeyxw7zp@jocasta.intra \
--to=john@darrington.wattle.id.au \
--cc=gdb-patches@sourceware.org \
--cc=kevinb@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