[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
ia64 .align big endian padding
From: |
Kevin Ryde |
Subject: |
ia64 .align big endian padding |
Date: |
Sun, 09 Nov 2003 07:25:06 +1000 |
User-agent: |
Gnus/5.1003 (Gnus v5.10.3) Emacs/21.3 (gnu/linux) |
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.
- ia64 .align big endian padding,
Kevin Ryde <=