align 的用法（u-boot源代码分析）

今决定认真分析一下u-boot的代码，但一开始就被“.balignl 16 0xdeadbeef”这条语句难住了，还好，google了一下，找到了《分析了一下 align 的用法》这篇文章，作者写得很好，看完后，我根据自己的实验结果，做了适当的更改，以让自己看起来更明白，把它记录如下：

.align 就是用来对齐的，究竟怎么对齐，有啥情况？下面分析一下

（一）

$vim align1.s

在新建的文件编辑以下代码：

_start:
    b reset
    .byte 0x55
    .byte 0xaa
reset:
    ldr r0, =0x53000000

保存后，执行如下命令：

$arm-linux-as align1.s -o align1.o

这样的话有的编译器可能会报错，但我的编译器没有报错，虽然没有报错，但反汇编的结果显示，运行时肯定会出问题。

执行如下命令：

$arm-linux-objdump -d align1.o

显示如下：

00000000 <_start>:
0: ea000000 b 4 <_start+0x4>
4: 0453aa55 ldreqb s1, [r3], -#2645

00000006 <reset>:
6: e3a00453 mov r0, #1392508928 ; 0x53000000

很明显，跳转语句应该跳到0x06处，而它却跳到0x04处，我们分析一下。首先，ARM指令都是32位的，这里要求4字节（一个word）对齐，b reset 指令占了4个字节，接着我们用 .byte 指令定义2个常数，因为这里是 byte 类型，所以只占了八位，两个数据，一共占16位。由于连接器内部有一个程序地址计数指针，里面保存着当前的地址，这地址指针是连接器内部工作需要的，我们不需要理会，只需要了解有这么一个机制。假如_start从0x00，第一条指令占4个byte，然后连续分配2个byte，当前地址指针应该是 0x06，那么问题来了，下条指令，也就是标号 reset 处的ldr指令，是一条ARM指令，这要求是 4个字节对齐的，当前的地址为 0x06，并不能满足这个要求，所以编译器自动将地址指针跳到0x04。

解决办法很简单，我们只需要加一条 .align 指令，问题就解决了

_start:
    b reset
    .byte 0x55
    .byte 0xaa
    .align
reset:
    ldr r0, =0x53000000

编译结果是：

00000000 <_start>:
0: ea000000 b 8 <reset>
4: 0000aa55 andeq sl, r0, r5, asr sl

00000008 <reset>:
8: e3a00453 mov r0, #1392508928 ; 0x53000000

在两个 .byte 指令后自动补零，直到满足地址要求为止。这里就是将地址累加到 0x08符合ARM指令要求，所以在这里写入下条指令。这是基本内容，下面研究一下其他

（二）.align 5

这里只是一个例子，重点想说的是这个 .align 5 后面的 5 究竟是什么意思？ uboot里面就有这指令。我们继续做做试验，看看编译结果是什么

_start:
    b reset

    .align 5
    .byte 0x55

    .align 5
    .byte 0xaa

    .align
reset:
    ldr r0, =0x53000000

编译结果：

00000000 <_start>:
0: ea00000f b 44 <reset>
...
20: 00000055 andeq r0, r0, r5, asr r0
...
40: 000000aa andeq r0, r0, sl, lsr #1

00000044 <reset>:
44: e3a00453 mov r0, #1392508928 ; 0x53000000

我们发现这编译结果有点意思，这地址分配一下子上去了，但是也不难，分析一下就OK，看那个 20 和 40 ，这里是十六进制，也就是 32 和 64了。那么很容易可以联想到，这里做的是幂运算，也就是 .align 5 对齐的地址为 2^5 = 32，之前的地址全部补零。

（三）.balignl 16,0xdeadbeef

_start:
    b reset

    .balignl 16,0xdeadbeef

reset:
    ldr r0, =0x53000000

在看uboot的时候还有这么一个语句，查了半天as的手册才找到，囧，不过稍微做了一下实现，觉得又不是很难，我们看看结果：

00000000 <_start>:
   0: ea000002 b 10 <reset>
   4: deadbeef cdple 14, 10, cr11, cr13, cr15, {7}
   8: deadbeef cdple 14, 10, cr11, cr13, cr15, {7}
   c: deadbeef cdple 14, 10, cr11, cr13, cr15, {7}

00000010 <reset>:
10: e3a00453 mov r0, #1392508928 ; 0x53000000

可以看出，这指令就是将 deadbeef字符串填进去，一共填到地址为16对齐的地方为指，上面可以看到，这里填到 0x10 也就是 16了。

转自:http://blogold.chinaunix.net/u3/94328/showart_1917728.html

转载于:https://www.cnblogs.com/hnrainll/archive/2011/06/14/2080243.html

align 的用法（u-boot源代码分析）相关推荐

《深入实践Spring Boot》阅读笔记之三：核心技术源代码分析
为什么80%的码农都做不了架构师?>>> 刚关注的朋友,可以回顾前两篇文章: 基础应用开发分布式应用开发上篇文章总结了<深入实践Spring Boot>的第二部 ...
Android系统进程间通信（IPC）机制Binder中的Server启动过程源代码分析
原文地址: http://blog.csdn.net/luoshengyang/article/details/6629298 在前面一篇文章浅谈Android系统进程间通信(IPC)机制Binder ...
Spring Security——OAuth 2.0 Client自动配置源代码分析
基本概念 OAuth2.0:OAuth2.0是OAuth协议的延续版本,但不向前兼容OAuth 1.0(即完全废止了OAuth1.0). OAuth 2.0关注客户端开发者的简易性.要么通过组织在资源 ...
《LINUX3.0内核源代码分析》第二章：中断和异常【转】
转自:http://blog.chinaunix.net/uid-25845340-id-2982887.html 摘要:第二章主要讲述linux如何处理ARM cortex A9多核处理器的中断.异 ...
Android系统匿名共享内存Ashmem（Anonymous Shared Memory）驱动程序源代码分析
文章转载至CSDN社区罗升阳的安卓之旅,原文地址:http://blog.csdn.net/luoshengyang/article/details/6664554 在上一文章Android系统匿名共 ...
浅谈:Spring Boot原理分析,切换内置web服务器,SpringBoot监听项目(使用springboot-admin),将springboot的项目打成war包
浅谈:Spring Boot原理分析(更多细节解释在代码注释中) 通过@EnableAutoConfiguration注解加载Springboot内置的自动初始化类(加载什么类是配置在spring.f ...
Android应用程序绑定服务（bindService）的过程源代码分析
Android应用程序组件Service与Activity一样,既可以在新的进程中启动,也可以在应用程序进程内部启动:前面我们已经分析了在新的进程中启动Service的过程,本文将要介绍在应用程序内部 ...
linux内核源代码分析----内核基础设施之klist
概述 klist是list的线程安全版本,他提供了整个链表的自旋锁,查找链表节点,对链表节点的插入和删除操作都要获得这个自旋锁.klist的节点数据结构是klist_node,klist_node引入 ...
arm linux head.s,arm-linux head.S 源代码分析
arm-linux head.S 源代码分析 arm-linux head.S 源代码分析这是ARM-Linux运行的第一个文件,这些代码是一个比较独立的代码包裹器.其作用就是解压Linux内核,并 ...

align 的用法（u-boot源代码分析）

align 的用法（u-boot源代码分析）相关推荐

最新文章

热门文章