This is the mail archive of the
gdb-patches@sourceware.org
mailing list for the GDB project.
Re: [PATCH] Record ARM THUMB2 PLD/PLI cache instructions
- From: Trent Piepho <tpiepho at impinj dot com>
- To: "simark at simark dot ca" <simark at simark dot ca>
- Cc: "gdb-patches at sourceware dot org" <gdb-patches at sourceware dot org>
- Date: Wed, 3 Oct 2018 00:34:07 +0000
- Subject: Re: [PATCH] Record ARM THUMB2 PLD/PLI cache instructions
- References: <20180928230437.4329-1-tpiepho@impinj.com> <cbf0d619-2307-855d-4620-373c6614d149@simark.ca> <1538431511.6709.18.camel@impinj.com> <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.