RFA: arm maverick disassembly

classic Classic list List threaded Threaded
3 messages Options
Reply | Threaded
Open this post in threaded view
|

RFA: arm maverick disassembly

James Lemke
I got a report of incorrect disassembly of mrc opcodes as cfmsub32.
E.G.
was         ee102610    cfmsub32    mvax0, mvfx2, mvfx0, mvfx0
should be   ee102610    mrc     6, 0, r2, cr0, cr0, {0}

I found that 6 of the Maverick CDP opcodes do not depend on bit 4 when
they should.  Patch attached.

Tested on x86-linux x arm-elf.
No change in binutils results.
gcc results had no regressions and 15 improvements:
2x unsupported -> pass  gcc.dg/cpp/trad/num-sign.c
13x untested -> pass gcc.dg/pch/valid-[123].c & warn-1.c

Not sure that this qualifies for the "obvious" rule.
OK to commit?

--
Jim Lemke   [hidden email]   Orillia, Ontario

cirrus-cdp.patch (3K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: RFA: arm maverick disassembly

Richard Earnshaw-2
On Fri, 2005-10-07 at 22:44, James Lemke wrote:

> I got a report of incorrect disassembly of mrc opcodes as cfmsub32.
> E.G.
> was         ee102610    cfmsub32    mvax0, mvfx2, mvfx0, mvfx0
> should be   ee102610    mrc     6, 0, r2, cr0, cr0, {0}
>
> I found that 6 of the Maverick CDP opcodes do not depend on bit 4 when
> they should.  Patch attached.
>
> Tested on x86-linux x arm-elf.
> No change in binutils results.
> gcc results had no regressions and 15 improvements:
> 2x unsupported -> pass  gcc.dg/cpp/trad/num-sign.c
> 13x untested -> pass gcc.dg/pch/valid-[123].c & warn-1.c
>
> Not sure that this qualifies for the "obvious" rule.
> OK to commit?

Thanks, I've put this in after updating it to the current sources.

For future reference, please don't send ChangeLog entries as diff
output, they almost never apply cleanly.

R.
Reply | Threaded
Open this post in threaded view
|

Re: RFA: arm maverick disassembly

Richard Earnshaw-2
On Sat, 2005-10-08 at 15:54, Richard Earnshaw wrote:

> On Fri, 2005-10-07 at 22:44, James Lemke wrote:
> > I got a report of incorrect disassembly of mrc opcodes as cfmsub32.
> > E.G.
> > was         ee102610    cfmsub32    mvax0, mvfx2, mvfx0, mvfx0
> > should be   ee102610    mrc     6, 0, r2, cr0, cr0, {0}
> >
> > I found that 6 of the Maverick CDP opcodes do not depend on bit 4 when
> > they should.  Patch attached.
> >
> > Tested on x86-linux x arm-elf.
> > No change in binutils results.
> > gcc results had no regressions and 15 improvements:
> > 2x unsupported -> pass  gcc.dg/cpp/trad/num-sign.c
> > 13x untested -> pass gcc.dg/pch/valid-[123].c & warn-1.c
> >
> > Not sure that this qualifies for the "obvious" rule.
> > OK to commit?
>
> Thanks, I've put this in after updating it to the current sources.
>
> For future reference, please don't send ChangeLog entries as diff
> output, they almost never apply cleanly.
Unfortunately this tripped a bug in the gas testsuite.  Fixed thusly:

2005-10-17  Richard Earnshaw  <[hidden email]>

        * gas/arm/copro.d: 'mcrlt' instruction should not be disassembled as
        'cfsh64lt'.





gas.patch (1K) Download Attachment