ia64 .align big endian padding

[Kevin Ryde]

In gas 2.12 on a ia64-hp-hpux11.22 system, a foo.s,

                .text
                .align  32
        { .mmi; add     r14 = r15, r16
                add     r17 = r18, r19
                add     r20 = r21, r22 ;; }
                .align  32
        { .mmi; add     r23 = r24, r25
                add     r26 = r27, r28
                add     r29 = r30, r31 ;; }

assembled with

        as foo.s

produces from objdump -d a.out,

        a.out:     file format elf32-ia64-hpux-big

        Disassembly of section .text:

        00000000 <.text>:
           0:   09 70 3c 20 00 20       [MMI]       add r14=r15,r16
           6:   10 91 4c 00 40 80                   add r17=r18,r19
           c:   52 b1 00 80                         add r20=r21,r22;;
          10:   00 04 00 00 00 00       [MII] (p32) break.m 0x0
          16:   02 00 00 00 00 01             (p08) break.i 0x0
          1c:   00 00 00 0c                         data8 0x1800000002
          20:   09 b8 60 32 00 20       [MMI]       add r23=r24,r25
          26:   a0 d9 70 00 40 a0                   add r26=r27,r28
          2c:   e3 f9 00 80                         add r29=r30,r31;;

Notice the "break" instructions inserted for the second .align.  I
believe these are incorrect and that they should be "nop"s.  (The
intel documentation calls for nop padding in text segments.)

Attempting to execute such code produced exceptions, so I think what
objdump is showing is what the code really is.

The problem doesn't seem to occur on little-endian systems, nops are
inserted there.  Adding .msb to force big-endian output on such a
system seems to reveal the problem though.

For what it's worth the padding bundle inserted looks like MFI nops
that have been byte-swapped.  If so then that's incorrect, I believe
code bytes are not affected by the data endianness mode.