From: Jeff Law via Gdb-patches <gdb-patches@sourceware.org>
To: gdb-patches@sourceware.org
Subject: Minor fix for H8 simulator
Date: Thu, 11 Nov 2021 09:50:54 -0700 [thread overview]
Message-ID: <36fb4284-5ddc-50c3-959c-b30e0cc96096@gmail.com> (raw)
[-- Attachment #1: Type: text/plain, Size: 1591 bytes --]
I haven't regularly contributed to gdb/sim for a long time. So please be
gentle if I goof on process stuff.
The upstream GCC tester has showed spurious execution failures on the
H8 target for the H8/SX multilibs. I suspected memory corruption or an
uninitialized variable early as the same binary would sometimes work and
sometimes it got the wrong result. Worse yet, the point where the test
determined it was getting the wrong result would change.
Because it only happened on the H8/SX variant I was able to zero in on
the "mova" support and the "short form" of those instructions in particular.
As the code stands it checks if code->op3.type == 0 to try and identify
cases where op3 wasn't filled in and thus we've got the short form of
the mova instruction.
But for the short-form of those instructions we never set any of the
"op3" data structure. We get whatever was lying around -- it's usually
zero and thus things usually work, but if the stale data was nonzero,
then we'd fail to recognize the instruction as a short-form and fail to
set up the various fields appropriately.
I initially initialized the op3.type field to zero, but didn't like that
because it was inconsistent with how other operands were initialized.
Bringing consistency meant using -1 as the initializer value and
adjusting the check for short form mova appropriately.
I've had this in the upstream GCC tester for perhaps a year at this
point and haven't seen any of the intermittent failures again.
OK to push to master (assuming I even still have permissions to do so)?
Thanks,
Jeff
[-- Attachment #2: 0006-h8simfix.patch --]
[-- Type: text/plain, Size: 753 bytes --]
* h8300/compile.c (decode): Initialize op3.type to -1.
(step_once): Adjust test of op3.type.
diff --git a/sim/h8300/compile.c b/sim/h8300/compile.c
index c1c61d8211..af9137d6d6 100644
--- a/sim/h8300/compile.c
+++ b/sim/h8300/compile.c
@@ -568,6 +568,7 @@ decode (SIM_DESC sd, int addr, unsigned char *data, decoded_inst *dst)
dst->dst.type = -1;
dst->src.type = -1;
+ dst->op3.type = -1;
/* Find the exact opcode/arg combo. */
for (q = h8_opcodes; q->name; q++)
@@ -1940,7 +1941,7 @@ step_once (SIM_DESC sd, SIM_CPU *cpu)
of the same register.
*/
- if (code->op3.type == 0)
+ if (code->op3.type == -1)
{
/* Short form: src == INDEXB/INDEXW, dst == op3 == 0.
We get to compose dst and op3 as follows:
next reply other threads:[~2021-11-11 16:52 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-11-11 16:50 Jeff Law via Gdb-patches [this message]
2021-11-11 17:55 ` Mike Frysinger via Gdb-patches
2021-11-11 18:06 ` Jeff Law via Gdb-patches
2021-11-11 21:16 ` Mike Frysinger via Gdb-patches
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=36fb4284-5ddc-50c3-959c-b30e0cc96096@gmail.com \
--to=gdb-patches@sourceware.org \
--cc=jeffreyalaw@gmail.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