From: Trent Piepho <tpiepho@impinj.com>
To: "simark@simark.ca" <simark@simark.ca>
Cc: "gdb-patches@sourceware.org" <gdb-patches@sourceware.org>
Subject: Re: [PATCH] Record ARM THUMB2 PLD/PLI cache instructions
Date: Wed, 03 Oct 2018 00:34:00 -0000 [thread overview]
Message-ID: <1538526847.6709.35.camel@impinj.com> (raw)
In-Reply-To: <c798b9e59e6dce71828eaa5266608aa0@simark.ca>
On Tue, 2018-10-02 at 13:19 -0400, Simon Marchi wrote:
> On 2018-10-01 18:05, Trent Piepho wrote:
> > > In the manual, however, in table "Table A5-20 Load byte, memory
> > > hints", some encodings with
> > > Rt == 0b1111 decode to "UNPREDICTABLE". Should the record fail for
> > > those? I think currently
> > > with your patch we will accept them. I am thinking it would be good
> > > to fail, because since
> > > we can't know the side effects of such instruction, we risk showing
> > > some false information if
> > > we just assume nothing has changed.
> >
> >
> > Rather than this, I used the thumb2 supplement I found here: http://her
> > mes.wings.cs.wisc.edu/files/Thumb-2SupplementReferenceManual.pdf
> >
> > Section 3.3.3 had the most useful table and exhaustive list of possible
> > encodings for this type of thumb2 instruction.
>
> Not sure which section 3.3.3 you are referring to. But I must have been
> using an outdated version of the manual, in the version you linked there
> is indeed no unpredictable encodings.
The Thumb-2SupplementReferenceManual.pdf file (link above, 1st google
hit for file name). It's not a full manual, just a thumb2 description.
I found the organization of the thumb2 decoding tables more useful in
that one than in the other manual, the full manual on ARM's site.
> > > If you are motivated, it would be nice to add a test for this
> > > instruction in arm_record_test,
> > > but I won't require it, since the current state is that this test
> > > isn't meant to test all
> > > possible instruction, and I don't want to impose that burden on you.
> >
> > I might that be THAT motivated, since I've never even used that test
> > feature.
>
> Err I'm not sure if you you meant that you are that motivated, or you
> are _not_ that motivated. In case you are, I'll be happy to provide any
> help you would need :).
Sorry, not that motivated. I wanted to make reverse debugging work on
ARM, and it works for me now. Don't really want to dive into adding
more to the self tests, which I've never used. There's really no call
to do that on company time anyway, while for reverse debugging there
was.
next prev parent reply other threads:[~2018-10-03 0:34 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-09-28 23:05 Trent Piepho
2018-09-30 14:22 ` Simon Marchi
2018-10-01 22:05 ` Trent Piepho
2018-10-02 17:19 ` Simon Marchi
2018-10-03 0:34 ` Trent Piepho [this message]
2018-10-03 17:19 ` Pedro Alves
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=1538526847.6709.35.camel@impinj.com \
--to=tpiepho@impinj.com \
--cc=gdb-patches@sourceware.org \
--cc=simark@simark.ca \
/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