[Bug binutils/10924] New: Bug in objdump when disassembling raw armv4t binaries

Instruction 0x002000b0 looks like a strheq instruction but it should be
unpredictable since the P bit is zero and W bit is 1.

Another reason it should be unpredictable is that when W is 1 you can have Rd ==
Rn.  

Perhaps returning undefined for all unpredictables would be a good idea?

That is my suggestion.  

Thoughts?

--
           Summary: Bug in objdump when disassembling raw armv4t binaries
           Product: binutils
           Version: 2.21 (HEAD)
            Status: NEW
          Severity: normal
          Priority: P2
         Component: binutils
        AssignedTo: unassigned at sources dot redhat dot com
        ReportedBy: chris at seberino dot org
                CC: bug-binutils at gnu dot org


http://sourceware.org/bugzilla/show_bug.cgi?id=10924

------- You are receiving this mail because: -------
You are on the CC list for the bug, or are watching someone who is.


_______________________________________________
bug-binutils mailing list
bug-binutils@...
http://lists.gnu.org/mailman/listinfo/bug-binutils

------- Additional Comments From nickc at redhat dot com  2009-11-10 10:29 -------
Created an attachment (id=4377)
 --> (http://sourceware.org/bugzilla/attachment.cgi?id=4377&action=view)
Add UNPREDICTABLE warning for insns which use Addressing Mode 3 and P == 0 and
W == 1


--


http://sourceware.org/bugzilla/show_bug.cgi?id=10924

------- You are receiving this mail because: -------
You are on the CC list for the bug, or are watching someone who is.


_______________________________________________
bug-binutils mailing list
bug-binutils@...
http://lists.gnu.org/mailman/listinfo/bug-binutils

------- Additional Comments From nickc at redhat dot com  2009-11-10 10:32 -------
Hi Chris,

  I am planning on applying the uploaded patch to address this issue, but I
would like your feedback on the new behaviour.  With the patch applied your
testcase will disassemble as:

  00000000 <.text>:
     0:   002000b0        strheq  r0, [r0], -r0 <UNPREDICTABLE>

I feel that displaying the disassembled instruction is correct, even though it
is unpredictable, since it is the behaviour of the instruction that cannot be
specified rather than the entire instruction being undefined.

What do you think ?

Cheers
  Nick


--
           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |WAITING


http://sourceware.org/bugzilla/show_bug.cgi?id=10924

------- You are receiving this mail because: -------
You are on the CC list for the bug, or are watching someone who is.


_______________________________________________
bug-binutils mailing list
bug-binutils@...
http://lists.gnu.org/mailman/listinfo/bug-binutils

------- Additional Comments From chris at seberino dot org  2009-11-10 17:31 -------
Subject: Re:  Bug in objdump when disassembling raw
        armv4t binaries

On Tue, Nov 10, 2009 at 10:32:26AM -0000, nickc at redhat dot com wrote:

>   I am planning on applying the uploaded patch to address this issue, but I
> would like your feedback on the new behaviour.  With the patch applied your
> testcase will disassemble as:
>
>   00000000 <.text>:
>      0:   002000b0        strheq  r0, [r0], -r0 <UNPREDICTABLE>
>
> I feel that displaying the disassembled instruction is correct, even though it
> is unpredictable, since it is the behaviour of the instruction that cannot be
> specified rather than the entire instruction being undefined.

Sounds good.  I would just suggest making the warning a comment so that
the output of objdump still can be run through gas.

e.g.

   00000000 <.text>:
       0:   002000b0        strheq  r0, [r0], -r0 ; UNPREDICTABLE

On another note, do you have any links explaining the hows and whys of
UNPREDICTABLEs?  How did you know "it is the behaviour of the instruction that
cannot be specified rather than the entire instruction being undefined" ?

cs


--


http://sourceware.org/bugzilla/show_bug.cgi?id=10924

------- You are receiving this mail because: -------
You are on the CC list for the bug, or are watching someone who is.


_______________________________________________
bug-binutils mailing list
bug-binutils@...
http://lists.gnu.org/mailman/listinfo/bug-binutils

------- Additional Comments From cvs-commit at gcc dot gnu dot org  2009-11-11 09:45 -------
Subject: Bug 10924

CVSROOT: /cvs/src
Module name: src
Changes by: nickc@... 2009-11-11 09:44:46

Modified files:
        opcodes        : ChangeLog arm-dis.c

Log message:
        PR binutils/10924
        * arm-dis.c (UNPREDICTABLE_INSTRUCTION): New macro.
        (print_insn_arm): Extend %s format control code to check for
        unpredictable addressing modes.  Add support for %S format control
        code which suppresses this check.
        (W_BIT, I_BIT, U_BIT, P_BIT): New macros.
        (WRITEBACK_BIT_SET, IMMEDIATE_BIT_SET, NEGATIVE_BIT_SET,
        PRE_BIT_SET): New macros.
        (print_insn_coprocessor): Use the new macros instead of magic
        constants.
        (print_arm_address): Likewise.
        (pirnt_insn_arm): Likewise.
        (print_insn_thumb32): Likewise.

Patches:
http://sources.redhat.com/cgi-bin/cvsweb.cgi/src/opcodes/ChangeLog.diff?cvsroot=src&r1=1.1492&r2=1.1493
http://sources.redhat.com/cgi-bin/cvsweb.cgi/src/opcodes/arm-dis.c.diff?cvsroot=src&r1=1.109&r2=1.110



--


http://sourceware.org/bugzilla/show_bug.cgi?id=10924

------- You are receiving this mail because: -------
You are on the CC list for the bug, or are watching someone who is.


_______________________________________________
bug-binutils mailing list
bug-binutils@...
http://lists.gnu.org/mailman/listinfo/bug-binutils

------- Additional Comments From nickc at redhat dot com  2009-11-11 09:54 -------
Hi Chris,

> I would just suggest making the warning a comment so that
> the output of objdump still can be run through gas.

Good point - I will make that change.

> On another note, do you have any links explaining the hows and whys
> of UNPREDICTABLEs?

Well basically it is what ARM have stated in their Architecture Reference
Manual.  In this particular case for example we had a mode 3 address with the P
bit clear (indicating post- addressing) and also the W bit clear (indicating no
writeback), which does not make any sense.  Why compute an address after the
memory access and then ignore it ?

What it really means is that ARM hardware implementers are free to do whatever
they like in UNPREDICTABLE situations.  So for example in this case the hardware
could assume that post- addressing always implies writeback and ignore the W
bit.  Or it could check the W bit and not update the address register.  Both
implementations would conform to the ARM specification but obviously would
confound any assembly code writers or compiler implementers.

> How did you know "it is the behaviour of the instruction that
> cannot be specified rather than the entire instruction being undefined" ?

What I meant was that the instruction itself is still defined.  (So for example
in the test case you supplied the instruction is still a store-half-word).  But
the exact behaviour of the side-effects of the instruction is undefined.  (So
again in the example the r0 register may or may not be updated with the post
computed address).


I have checked the patch in, but I will leave this issue open for reports of
other UNPREDICTABLE bit patterns.

Cheers
  Nick


--


http://sourceware.org/bugzilla/show_bug.cgi?id=10924

------- You are receiving this mail because: -------
You are on the CC list for the bug, or are watching someone who is.


_______________________________________________
bug-binutils mailing list
bug-binutils@...
http://lists.gnu.org/mailman/listinfo/bug-binutils

------- Additional Comments From chris at seberino dot org  2009-11-14 23:38 -------
Subject: Re:  Bug in objdump when disassembling raw
        armv4t binaries

On Wed, Nov 11, 2009 at 09:54:45AM -0000, nickc at redhat dot com wrote:
> I have checked the patch in, but I will leave this issue open for reports of
> other UNPREDICTABLE bit patterns.

Nick

OK I tried to find all bugs I could in one pass to make your job easier.

Regarding me helping with writing patches, I'll do it if I need to but it is
enough work just to inspect all this output to find the bugs in the first
place.  I'd be afraid of making a mistake.  Is there a specific file you could
point me to where all this parsing takes place?  I'll have a look.

I assume have unit tests you run your patches through so we know we aren't adding
new bugs as we fix existing ones?  And, I assume you are testing what I say
against the ARM manual so that *I* don't introduce a bug?

...

Here is what I found recently.  BTW, when I give you an example of a bug, it is most
likely found in other instructions.  I'm hoping that your fix ends up
eliminating the whole *class* of bugs.  For example, that last undefined bug
regarding P=0 and W=1 was reported for a store.  It also shows up in ldrsb and ldrh.
I hope you patch nailed those too?

Without further ado....

0x004000b0 strheq r0, [r0], #-0  <--- objdump is missing the "#-0" (see ARM-ARM top of A5-45)

0x004f00b1 strheq r0, [pc], #-1  <--- objdump has r0, [pc, #-1]

0x005fffff ldrsheq pc, [pc], #-255 <--- objdump has pc, [pc, #-255]

0x00500090 <-- should be undefined not ldrbeq

0x006fffbf <-- P=0 so can't be right

0x00700090 bit 26 is zero so can't be ldrbeq...I think it is undefined

0x007fffff ldrsheq pc, [pc, #-255]! <-- objdump is missing the "!" since bit 21=1

0x00cf00b0 strheq r0, [pc], #0 <--- objdump has r0, [pc, #0]  (bit24=0)
  (likewise for 0x00df00b0 and 0x00dfffff)

0x00ffffff ldrsheq pc, [pc, #255] <-- can't be right since P=0

0x0100f000 <-- obdjump say this is a tstpeq....What is tstp? No such thing!

0x01100090 <-- Can't be ldrbeq since bit26 is zero.  I think is undefined

0x0120f096 <-- objdump has "<illegal shifter operand>".  That should be fixed.

0x01300090 <--Can't be ldrbeq since bit26 =0.  I think is undefined.

0x01400000 <-- Should be mrseq not cmpeq since bit 20=0

0x016000b0 strheq r0, [r0, #-0]! <-- objdump has r0, [r0]! which is wrong

cs


--


http://sourceware.org/bugzilla/show_bug.cgi?id=10924

------- You are receiving this mail because: -------
You are on the CC list for the bug, or are watching someone who is.


_______________________________________________
bug-binutils mailing list
bug-binutils@...
http://lists.gnu.org/mailman/listinfo/bug-binutils

------- Additional Comments From cvs-commit at gcc dot gnu dot org  2009-11-17 17:20 -------
Subject: Bug 10924

CVSROOT: /cvs/src
Module name: src
Changes by: nickc@... 2009-11-17 17:20:26

Modified files:
        gas/testsuite  : ChangeLog
        gas/testsuite/gas/arm: arch4t-eabi.d arch4t.d archv6t2.d arm7t.d
                               inst.d vfma1.d xscale.d
        opcodes        : ChangeLog arm-dis.c

Log message:
        * gas/arm/vfma1.d: Only run on ELF based targets.
       
        PR binutils/10924
        * gas/arm/arch4t-eabi.d: Update expected disassembly.
        * gas/arm/arch4t.d: Likewise.
        * gas/arm/archv6t2.d: Likewise.
        * gas/arm/arm7t.d: Likewise.
        * gas/arm/inst.d: Likewise.
        * gas/arm/xscale.d: Likewise.
       
        PR binutils/10924
        * arm-dis.c (arm_opcodes): Add patterns to match undefined LDRB
        instruction variants.  Add pattern for MRS variant that was being
        confused with CMP.
        (arm_decode_shift): Place error message in a comment.
        (print_insn_arm): Note that writing back to the PC is
        unpredictable.
        Only print 'p' variants of cmp/cmn/teq/tst instructions if
        decoding for pre-V6 architectures.

Patches:
http://sources.redhat.com/cgi-bin/cvsweb.cgi/src/gas/testsuite/ChangeLog.diff?cvsroot=src&r1=1.1591&r2=1.1592
http://sources.redhat.com/cgi-bin/cvsweb.cgi/src/gas/testsuite/gas/arm/arch4t-eabi.d.diff?cvsroot=src&r1=1.2&r2=1.3
http://sources.redhat.com/cgi-bin/cvsweb.cgi/src/gas/testsuite/gas/arm/arch4t.d.diff?cvsroot=src&r1=1.5&r2=1.6
http://sources.redhat.com/cgi-bin/cvsweb.cgi/src/gas/testsuite/gas/arm/archv6t2.d.diff?cvsroot=src&r1=1.4&r2=1.5
http://sources.redhat.com/cgi-bin/cvsweb.cgi/src/gas/testsuite/gas/arm/arm7t.d.diff?cvsroot=src&r1=1.16&r2=1.17
http://sources.redhat.com/cgi-bin/cvsweb.cgi/src/gas/testsuite/gas/arm/inst.d.diff?cvsroot=src&r1=1.18&r2=1.19
http://sources.redhat.com/cgi-bin/cvsweb.cgi/src/gas/testsuite/gas/arm/vfma1.d.diff?cvsroot=src&r1=1.1&r2=1.2
http://sources.redhat.com/cgi-bin/cvsweb.cgi/src/gas/testsuite/gas/arm/xscale.d.diff?cvsroot=src&r1=1.10&r2=1.11
http://sources.redhat.com/cgi-bin/cvsweb.cgi/src/opcodes/ChangeLog.diff?cvsroot=src&r1=1.1502&r2=1.1503
http://sources.redhat.com/cgi-bin/cvsweb.cgi/src/opcodes/arm-dis.c.diff?cvsroot=src&r1=1.112&r2=1.113



--


http://sourceware.org/bugzilla/show_bug.cgi?id=10924

------- You are receiving this mail because: -------
You are on the CC list for the bug, or are watching someone who is.


_______________________________________________
bug-binutils mailing list
bug-binutils@...
http://lists.gnu.org/mailman/listinfo/bug-binutils

------- Additional Comments From nickc at redhat dot com  2009-11-17 17:22 -------
Created an attachment (id=4392)
 --> (http://sourceware.org/bugzilla/attachment.cgi?id=4392&action=view)
More fixes


--


http://sourceware.org/bugzilla/show_bug.cgi?id=10924

------- You are receiving this mail because: -------
You are on the CC list for the bug, or are watching someone who is.


_______________________________________________
bug-binutils mailing list
bug-binutils@...
http://lists.gnu.org/mailman/listinfo/bug-binutils

------- Additional Comments From nickc at redhat dot com  2009-11-17 17:25 -------
Hi Chris,

  Right - I have checked in the newly uploaded pr10924_arm_dis.c_patch.2 which
handles all of the new test cases you found.

  With regard to the TSTP instruction, it is a real instruction, but an obsolete
one.  The patch takes care of this as well.

  Let me know if you find any more bad instruction patterns.

Cheers
  Nick

--


http://sourceware.org/bugzilla/show_bug.cgi?id=10924

------- You are receiving this mail because: -------
You are on the CC list for the bug, or are watching someone who is.


_______________________________________________
bug-binutils mailing list
bug-binutils@...
http://lists.gnu.org/mailman/listinfo/bug-binutils

------- Additional Comments From chris at seberino dot org  2009-11-17 17:57 -------
Subject: Re:  Bug in objdump when disassembling raw
        armv4t binaries

On Tue, Nov 17, 2009 at 05:25:50PM -0000, nickc at redhat dot com wrote:
>   Right - I have checked in the newly uploaded pr10924_arm_dis.c_patch.2 which
> handles all of the new test cases you found.
>
>   With regard to the TSTP instruction, it is a real instruction, but an obsolete
> one.  The patch takes care of this as well.
>
>   Let me know if you find any more bad instruction patterns.

Thanks will do.  Glad I can help.  On another note, do you have any tricks to
make me feel confident we aren't introducing bugs?  I don't suppose ARM has a
blessed disassembler we can compare against?  Or, do you have rock solid
comprehensive unit tests against gas?

cs


--


http://sourceware.org/bugzilla/show_bug.cgi?id=10924

------- You are receiving this mail because: -------
You are on the CC list for the bug, or are watching someone who is.


_______________________________________________
bug-binutils mailing list
bug-binutils@...
http://lists.gnu.org/mailman/listinfo/bug-binutils

------- Additional Comments From nickc at redhat dot com  2009-11-18 09:14 -------
Hi Chris,

> On another note, do you have any tricks to make me feel confident we aren't
> introducing bugs?

Tricks no.  But the newly patched disassembler does not introduce any
regressions into the GAS testsuite for any of the ARM based toolchains.  (I
checked).

> I don't suppose ARM has a blessed disassembler we can compare against?

They do have a disassembler, if you are prepared to pay for it.  

If anyone does have access to this tool and notices any discrepancies when
comparing the results against objdump then they are free to report them and I
will be happy to investigate.

>  Or, do you have rock solid comprehensive unit tests against gas?

Rock solid, no.  Reasonable yes.  The gas testsuite does not check every
possible legal and illegal ARM binary pattern, but it does cover a reasonable
range of the instructions.

Cheers
  Nick
 

--


http://sourceware.org/bugzilla/show_bug.cgi?id=10924

------- You are receiving this mail because: -------
You are on the CC list for the bug, or are watching someone who is.


_______________________________________________
bug-binutils mailing list
bug-binutils@...
http://lists.gnu.org/mailman/listinfo/bug-binutils

------- Additional Comments From drow at sources dot redhat dot com  2009-11-18 16:14 -------
Hi Nick,

Thoms Schwinge noticed a failure in group-relocations.d:

    regexp_diff match failure
    regexp "^    8074:      e1c020d0        ldrd    r2, \[r0\]$"
    line   "    8074:       e1c020d0        ldrd    r2, [r0, #0]"

Is this change really needed?  I think Chris's point was that we have to print
"[r0, #-0]" which is a separate instruction from "[r0, #0]".


--


http://sourceware.org/bugzilla/show_bug.cgi?id=10924

------- You are receiving this mail because: -------
You are on the CC list for the bug, or are watching someone who is.


_______________________________________________
bug-binutils mailing list
bug-binutils@...
http://lists.gnu.org/mailman/listinfo/bug-binutils

[Nick Clifton]

Hi Daniel,

> Thoms Schwinge noticed a failure in group-relocations.d:
>
>     regexp_diff match failure
>     regexp "^    8074:      e1c020d0        ldrd    r2, \[r0\]$"
>     line   "    8074:       e1c020d0        ldrd    r2, [r0, #0]"

Oops, I thought that I had caught all of these.

> Is this change really needed?  I think Chris's point was that we have to print
> "[r0, #-0]" which is a separate instruction from "[r0, #0]".

Actually I think that he was referring to the compulsory presence of the
offset, even if it is zero, in the pre-indexed form of addressing.

You are correct though, the immediate value is not needed when using
offset addressing.  I'll create a patch to fix this and post it later.

Cheers
   Nick




_______________________________________________
bug-binutils mailing list
bug-binutils@...
http://lists.gnu.org/mailman/listinfo/bug-binutils

------- Additional Comments From nickc at redhat dot com  2009-11-18 17:07 -------
Subject: Re:  Bug in objdump when disassembling raw armv4t
 binaries

Hi Daniel,

> Thoms Schwinge noticed a failure in group-relocations.d:
>
>     regexp_diff match failure
>     regexp "^    8074:      e1c020d0        ldrd    r2, \[r0\]$"
>     line   "    8074:       e1c020d0        ldrd    r2, [r0, #0]"

Oops, I thought that I had caught all of these.

> Is this change really needed?  I think Chris's point was that we have to print
> "[r0, #-0]" which is a separate instruction from "[r0, #0]".

Actually I think that he was referring to the compulsory presence of the
offset, even if it is zero, in the pre-indexed form of addressing.

You are correct though, the immediate value is not needed when using
offset addressing.  I'll create a patch to fix this and post it later.

Cheers
   Nick




--


http://sourceware.org/bugzilla/show_bug.cgi?id=10924

------- You are receiving this mail because: -------
You are on the CC list for the bug, or are watching someone who is.


_______________________________________________
bug-binutils mailing list
bug-binutils@...
http://lists.gnu.org/mailman/listinfo/bug-binutils

------- Additional Comments From chris at seberino dot org  2009-11-18 18:17 -------
Subject: Re:  Bug in objdump when disassembling raw
        armv4t binaries

On Wed, Nov 18, 2009 at 05:07:14PM -0000, nickc at redhat dot com wrote:
> Actually I think that he was referring to the compulsory presence of the
> offset, even if it is zero, in the pre-indexed form of addressing.

Just to make sure we're clear....my understanding of my ARM manual is that we
need to specify #0 just like any other number.

cs


--


http://sourceware.org/bugzilla/show_bug.cgi?id=10924

------- You are receiving this mail because: -------
You are on the CC list for the bug, or are watching someone who is.


_______________________________________________
bug-binutils mailing list
bug-binutils@...
http://lists.gnu.org/mailman/listinfo/bug-binutils

------- Additional Comments From nickc at redhat dot com  2009-11-19 11:15 -------
Hi Chris,

> Just to make sure we're clear....my understanding of my ARM manual is that
> we need to specify #0 just like any other number.

Not quite.  There is one form of Addressing Mode 3 where the #0 is optional.
This is Immediate Offset addressing (see page A5-36 of the ARM ARM that you are
using).

Cheers
  Nick


--


http://sourceware.org/bugzilla/show_bug.cgi?id=10924

------- You are receiving this mail because: -------
You are on the CC list for the bug, or are watching someone who is.


_______________________________________________
bug-binutils mailing list
bug-binutils@...
http://lists.gnu.org/mailman/listinfo/bug-binutils

------- Additional Comments From nickc at redhat dot com  2009-11-19 14:01 -------
Created an attachment (id=4396)
 --> (http://sourceware.org/bugzilla/attachment.cgi?id=4396&action=view)
Do not prnt zero offset for Immediate Offset addressing


--


http://sourceware.org/bugzilla/show_bug.cgi?id=10924

------- You are receiving this mail because: -------
You are on the CC list for the bug, or are watching someone who is.


_______________________________________________
bug-binutils mailing list
bug-binutils@...
http://lists.gnu.org/mailman/listinfo/bug-binutils

------- Additional Comments From nickc at redhat dot com  2009-11-19 14:03 -------
Hi Guys,

  Right - I have checked in the third patch in this series.  This restores the
default behaviour of not printing a zero offset if it is used in Immediate
Offset addressing mode.  This also resovles the group-relocations.[sd] linker
testsuite regression reported by Daniel.

Cheers
  Nick


--


http://sourceware.org/bugzilla/show_bug.cgi?id=10924

------- You are receiving this mail because: -------
You are on the CC list for the bug, or are watching someone who is.


_______________________________________________
bug-binutils mailing list
bug-binutils@...
http://lists.gnu.org/mailman/listinfo/bug-binutils

------- Additional Comments From cvs-commit at gcc dot gnu dot org  2009-11-19 14:07 -------
Subject: Bug 10924

CVSROOT: /cvs/src
Module name: src
Changes by: nickc@... 2009-11-19 14:07:11

Modified files:
        opcodes        : ChangeLog arm-dis.c
        gas/testsuite  : ChangeLog
        gas/testsuite/gas/arm: arch4t-eabi.d arch4t.d arm7t.d armv1.d
                               wince_inst.d xscale.d

Log message:
        PR binutils/10924
        * gas/arm/arch4t-eabi.d: Restore previous expected dissambly of
        instructions using Immediate Offset addressing with an offset of
        zero.
        * gas/arm/arch4t.d: Likewise.
        * gas/arm/arm7t.d: Likewise.
        * gas/arm/xscale.d: Likewise.
        * gas/arm/wince-inst.d: Remove 'p' suffix from cmp, cmn, teq and
        tst instructions.
       
        PR binutils/10924
        * arm-dis.c (print_insn_arm): Do not print an offset of zero when
        decoding Immediaate Offset addressing.

Patches:
http://sources.redhat.com/cgi-bin/cvsweb.cgi/src/opcodes/ChangeLog.diff?cvsroot=src&r1=1.1506&r2=1.1507
http://sources.redhat.com/cgi-bin/cvsweb.cgi/src/opcodes/arm-dis.c.diff?cvsroot=src&r1=1.113&r2=1.114
http://sources.redhat.com/cgi-bin/cvsweb.cgi/src/gas/testsuite/ChangeLog.diff?cvsroot=src&r1=1.1596&r2=1.1597
http://sources.redhat.com/cgi-bin/cvsweb.cgi/src/gas/testsuite/gas/arm/arch4t-eabi.d.diff?cvsroot=src&r1=1.3&r2=1.4
http://sources.redhat.com/cgi-bin/cvsweb.cgi/src/gas/testsuite/gas/arm/arch4t.d.diff?cvsroot=src&r1=1.6&r2=1.7
http://sources.redhat.com/cgi-bin/cvsweb.cgi/src/gas/testsuite/gas/arm/arm7t.d.diff?cvsroot=src&r1=1.17&r2=1.18
http://sources.redhat.com/cgi-bin/cvsweb.cgi/src/gas/testsuite/gas/arm/armv1.d.diff?cvsroot=src&r1=1.6&r2=1.7
http://sources.redhat.com/cgi-bin/cvsweb.cgi/src/gas/testsuite/gas/arm/wince_inst.d.diff?cvsroot=src&r1=1.7&r2=1.8
http://sources.redhat.com/cgi-bin/cvsweb.cgi/src/gas/testsuite/gas/arm/xscale.d.diff?cvsroot=src&r1=1.11&r2=1.12



--


http://sourceware.org/bugzilla/show_bug.cgi?id=10924

------- You are receiving this mail because: -------
You are on the CC list for the bug, or are watching someone who is.


_______________________________________________
bug-binutils mailing list
bug-binutils@...
http://lists.gnu.org/mailman/listinfo/bug-binutils