java 0xdeadbeef_U-boot 中的 .balignl 16 0xdeadbeef 说明

U-boot 版本：1.2.0

在 U-boot 的 cpu/arm920t/start.S 里有一处代码为 .balignl 16 0xdeadbeef  ，初一看不知道意欲何为，但从伪指令 .balignl 来看，实际上就是对齐。对于某些处理器来说，所编写的代码不对齐并不会报错，但编译器为了优化，也可能会自动帮你对齐。但对于另外一些处理器的编译器来说，汇编代码里必须手动保持对齐，否则编译器会报错，像上面 ARM 处理器就是如此。

比如我们有一小段汇编代码：

_start:

b reset

nop

.byte 0xff

reset:

ldr r0, =0x40000000

首先说明一点，在 ARM 中，指令时要求是 32 位对齐的。从上面的代码来看，b reset 这条为 4 个字节，但接下来的 .byte 0xff 定义会让对齐失效。我们用 linux 上的交叉编译器来编译，也能看出来：

[root@CentOS ARM]# arm-linux-as align.s -o aslign.o

align.s: Assembler messages:

align.s:3: Error: misaligned branch destination

这里的编译器版本是：

[root@centos ARM]# arm-linux-as --version

GNU assembler (GNU Binutils) 2.20

需要注意的是，有些编译器并不会报错(往往版本较为老些)，而是它帮你做了优化，帮助你对齐。

这里，为了对齐，我们可以手动修改代码为：

_start:

b reset

nop

.byte 0xff

.align

reset:

ldr r0, =0x40000000

这样，编译就不会出错了! 接下来，使用 arm-linux-objdump 来看一下反汇编代码：

[root@centos ARM]# arm-linux-objdump -d aslign.o

aslign.o:    file format elf32-littlearm

Disassembly of section .text:

00000000 <_start>:

0:  ea000001        b      c

4:  e1a00000        nop                    ; (mov r0, r0)

8:  ff                .byte  0xff

9:  00              .byte  0x00

...

0000000c :

c:  e3a00101        mov    r0, #1073741824 ; 0x40000000

从上面可以看到，最后一跳指令所在地址 0xc 是 4 字节对其的。从地址 0x8 开始，依次存放了 .byte 0xff , .byte 0x00, .byte 0x00, .byte 0x00 这 4 个字节，使代码得到了对齐！

在以前的一些帖子里也有讲过(比如《硬编码》里)，CPU 对待数据和指令代码其实是一样的。基于这个道理，上面依次定义的 4 个字节，凑起来其实也是一条指令，这可以用 arm-linux-objdump 的 -D 参数查看之：

# arm-linux-objdump -D aslign.o

aslign.o:    file format elf32-littlearm

Disassembly of section .text:

00000000 <_start>:

0:  ea000001        b      c

4:  e1a00000        nop                    ; (mov r0, r0)

8:  000000ff        strdeq  r0, [r0], -pc

0000000c :

  c:  e3a00101        mov    r0, #1073741824 ; 0x40000000