Mirror of the gdb-patches mailing list
 help / color / mirror / Atom feed
From: Jeff Law via Gdb-patches <gdb-patches@sourceware.org>
To: gdb-patches@sourceware.org
Subject: Re: Minor fix for H8 simulator
Date: Thu, 11 Nov 2021 11:06:00 -0700	[thread overview]
Message-ID: <e1c101cf-dc1a-4450-cc04-ac26178c31ce@gmail.com> (raw)
In-Reply-To: <YY1ZC4t7RweOWFtY@vapier>



On 11/11/2021 10:55 AM, Mike Frysinger wrote:
> On 11 Nov 2021 09:50, Jeff Law via Gdb-patches wrote:
>> 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.
> can you update the unittests too ?
IIRC it was dependent upon what instructions had recently executed as 
those impacted the state of code->op3.type -- my analysis is from over a 
year ago and had been sitting in my todo box for a while.  Even just 
reproducing was fairly painful.

>
> and while we have your eyes on H8, can you perhaps peek at the open reports ?
> https://sourceware.org/bugzilla/buglist.cgi?bug_status=UNCONFIRMED&bug_status=NEW&bug_status=ASSIGNED&component=sim&&short_desc=h8300&short_desc_type=allwordssubstr
I can take a look at them as I'm familiar with the H8/S and earlier 
ISAs.  I've got virtually no experience with the SX variants.

Jeff

  reply	other threads:[~2021-11-11 18:06 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-11-11 16:50 Jeff Law via Gdb-patches
2021-11-11 17:55 ` Mike Frysinger via Gdb-patches
2021-11-11 18:06   ` Jeff Law via Gdb-patches [this message]
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=e1c101cf-dc1a-4450-cc04-ac26178c31ce@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