ART深入浅出(7) - OAT文件的格式

本文基于Android 7.1,不过因为从BSP拿到的版本略有区别,所以本文提到的源码未必与读者找到的源码完全一致。本文在提供源码片断时,将按照 <源码相对android工程的路径>:<行号> <类名> <函数名> 的方式,如果行号对不上,请参考类名和函数名来找到对应的源码。

了解ART的基本运作原理,就需要了解ART编译出的代码是怎么运行的。我们将使用oatdump得到的代码,进行仔细分析。

从简单示例出发

以一个非常简单的函数为例:
frameworks/base/core/java/android/app/Activity.java:988

988    public void onCreate(@Nullable Bundle savedInstanceState,
989            @Nullable PersistableBundle persistentState) {
990        onCreate(savedInstanceState);
991    }

这个函数,仅仅是调用了同名的onCreate函数的实现。
编译成oat文件后(存放在boot.oat内),用oatdump出来,我找到对应的dex代码

  129: void android.app.Activity.onCreate(android.os.Bundle, android.os.PersistableBundle) (dex_method_idx=2085)
    DEX CODE:
      0x0000: 6e20 2408 1000            | invoke-virtual {v0, v1}, void android.app.Activity.onCreate(android.os.Bundle) // method@2084
      0x0003: 0e00                      | return-void

这个dex代码看起来也非常简单。
接下来,我们看看编译出的机器码,反汇编后是什么:

    QuickMethodFrameInfo
      frame_size_in_bytes: 48
      core_spill_mask: 0x000040e0 (r5, r6, r7, r14)
      fp_spill_mask: 0x00000000 
      vr_stack_locations:
        ins: v0[sp + #52] v1[sp + #56] v2[sp + #60]
        method*: v3[sp + #0]
        outs: v0[sp + #4] v1[sp + #8]
    CODE: (code_offset=0x0337a6d5 size_offset=0x0337a6d0 size=66)...
      0x0337a6d4: f5ad5c00  sub     r12, sp, #8192
      0x0337a6d8: f8dcc000  ldr.w   r12, [r12, #0]
        StackMap [native_pc=0x337a6dd] (dex_pc=0x0, native_pc_offset=0x8, dex_register_map_offset=0xffffffff, inline_info_offset=0xffffffff, register_mask=0x0, stack_mask=0b000000)
      0x0337a6dc: b5e0      push    {r5, r6, r7, lr}
      0x0337a6de: b088      sub     sp, sp, #32
      0x0337a6e0: 9000      str     r0, [sp, #0]
      0x0337a6e2: f8b9c000  ldrh.w  r12, [r9, #0]  ; state_and_flags
      0x0337a6e6: f1bc0f00  cmp.w   r12, #0
      0x0337a6ea: d10a      bne     +20 (0x0337a702)
      0x0337a6ec: 461d      mov     r5, r3
      0x0337a6ee: 460e      mov     r6, r1
      0x0337a6f0: 4617      mov     r7, r2
      0x0337a6f2: 6808      ldr     r0, [r1, #0]
      0x0337a6f4: f8d004c8  ldr.w   r0, [r0, #1224]
      0x0337a6f8: f8d0e020  ldr.w   lr, [r0, #32]
      0x0337a6fc: 47f0      blx     lr
        StackMap [native_pc=0x337a6ff] (dex_pc=0x0, native_pc_offset=0x2a, dex_register_map_offset=0x0, inline_info_offset=0xffffffff, register_mask=0xe0, stack_mask=0b000000)
          v0: in register (6)   [entry 0]
          v1: in register (7)   [entry 1]
          v2: in register (5)   [entry 2]
      0x0337a6fe: b008      add     sp, sp, #32
      0x0337a700: bde0      pop     {r5, r6, r7, pc}
      0x0337a702: 9103      str     r1, [sp, #12]
      0x0337a704: 9204      str     r2, [sp, #16]
      0x0337a706: 9305      str     r3, [sp, #20]
      0x0337a708: f8d9e2a8  ldr.w   lr, [r9, #680]  ; pTestSuspend
      0x0337a70c: 47f0      blx     lr
        StackMap [native_pc=0x337a70f] (dex_pc=0x0, native_pc_offset=0x3a, dex_register_map_offset=0x3, inline_info_offset=0xffffffff, register_mask=0x0, stack_mask=0b111000)
          v0: in stack (12) [entry 3]
          v1: in stack (16) [entry 4]
          v2: in stack (20) [entry 5]
      0x0337a70e: 9903      ldr     r1, [sp, #12]
      0x0337a710: 9a04      ldr     r2, [sp, #16]
      0x0337a712: 9b05      ldr     r3, [sp, #20]
      0x0337a714: e7ea      b       -44 (0x0337a6ec)

这个代码很长,你也许会奇怪,为什么简单的一句源码,会产生如此多的机器码呢?下面我为大家分段解析。
解析时,请大家注意对照我说的部分

QuickMethodFrameInfo

首先,看到的”QuickMethodFrameInfo”部分,定义了相关代码的信息,包含:frame_size_in_bytes: 这个信息指出堆栈的大小。该例子中的值是48。下面的机器码中(0x0337a6dc-0x0337a6de),我们可以看到push指令和sub指令正好占用了堆栈的48字节。
core_spill_mask: 需要保存的寄存器值。这个值是0x000040e0,对应的就是0x337a6dc的 push {r5, r6, r7, lr} (lr即r14)。
vr_stack_locations: 则定义了dex寄存器在堆栈上的位置。

Code部分

接下来,CODE部分,包含了所有相关的代码。CODE部分包括5部分:
1. 堆栈检测部分:0x0337a6d4-0x337a6d8,检测现在的堆栈是否溢出的,否则将会产生一个堆栈溢出的错误
2. 程序头部分:0x0337a6dc-0x0337a6f0, 主要是保护现场,保存参数,检查停止点等
3. 程序正文部分:0x0337a6f2-0x0337a6fc,dex字节码的实现部分
4. 程序结尾部分:0x0337a6fe-0x0337a700 负责恢复现场,然后返回
5. 执行检查点部分:0x0337a702-0x0337a714: 调用检查点,执行一些任务,比如GC等等。
这些部分,包含了一个程序大部分组成。
第一部分的堆栈检测比较简单,我们不详细说了,从第二部分开始。

程序头部分

这一部分的代码

      0x0337a6dc: b5e0      push    {r5, r6, r7, lr}
      0x0337a6de: b088      sub     sp, sp, #32
      0x0337a6e0: 9000      str     r0, [sp, #0]
      0x0337a6e2: f8b9c000  ldrh.w  r12, [r9, #0]  ; state_and_flags
      0x0337a6e6: f1bc0f00  cmp.w   r12, #0
      0x0337a6ea: d10a      bne     +20 (0x0337a702)
      0x0337a6ec: 461d      mov     r5, r3
      0x0337a6ee: 460e      mov     r6, r1
      0x0337a6f0: 4617      mov     r7, r2

需要注意的是,在ART里面,参数传递是使用r0~r3 (ARM架构),这一点与标准的C stdcall是一样的。不过,r0是被固定为参数ArtMethod*,即目前被调用函数的指针,如果是非static函数,那么r1则是this指针,否则r1就是第一个参数。依次是java函数中声明的其他参数。
如果参数超过了寄存器的数目,则用堆栈传递。关于堆栈传递参数的方法,我们会在后面章节中详细说明。
这里看到,前两条语句是保存寄存器并分配堆栈。第3条语句(0x0337a6e0) 将r0(ArtMethod*)的值放在了栈顶。这是ART的规范要求,所有的java method,必须在堆栈上放入它的函数指针,这样在遍历栈的时候,ART就知道这个栈归属哪个函数。
第4~6句 (0x0337a6e2-0x0337a6ea) 是读取 Thread对象的state_and_flags成员,判断是否有检查点,如果有则转到检查点来执行。
r9参数总是放的当前线程的Thread对象指针。
第7句以后,则是保存参数到寄存器中,以便后面使用(实际上并没有使用,这说明ART的编译器还存在优化的空间)。

调用部分

要调用一个函数,ART必须做的事情是:1. 得到这个函数的入口地址;2. 准备参数;3. 调用

      0x0337a6f2: 6808      ldr     r0, [r1, #0]
      0x0337a6f4: f8d004c8  ldr.w   r0, [r0, #1224]
      0x0337a6f8: f8d0e020  ldr.w   lr, [r0, #32]
      0x0337a6fc: 47f0      blx     lr

在这里,r1是this指针,第0x0337a6f2是取得this的class对象,放到r0,然后从r0中取得被调用的onCreate函数的ArtMethod*指针,再保存到r0中。第三步是从ArtMethod中取得入口地址(放在32偏移处),最后调用。
onCreate(Bundle) 函数需要3个参数:
r0: 指向onCreate(Bundle)的ArtMethod*;
r1: this指针
r2: Bundle对象指针。
我们看到,ART巧妙的将ArtMethod的值取到R0后,就把它作为参数来使用。而r1,r2的值自进入函数后就没有被改变,所以就直接使用了。
最后一步调用blx跳转到函数入口。 blx指令是跳转到寄存器指定的地址,同时把下条指令的地址放入到lr寄存器,方便函数调用后返回。

程序结束部分

这部分很简单,就是恢复堆栈和寄存器。
因为这个函数没有返回值,所以这里省略了返回值的处理。正常情况下,返回值是放在r0,r1寄存器内的。

检查点调用部分

检查点是ART内一个非常重要的功能,ART依靠检查点来实现GC、异常处理等一系列关键功能。
ART为每个线程都分配了一个Thread对象,这个对象中有一个pTestSuspend入口,这个入口就是用来执行检查点函数调用的。

      0x0337a702: 9103      str     r1, [sp, #12]
      0x0337a704: 9204      str     r2, [sp, #16]
      0x0337a706: 9305      str     r3, [sp, #20]
      0x0337a708: f8d9e2a8  ldr.w   lr, [r9, #680]  ; pTestSuspend
      0x0337a70c: 47f0      blx     lr
      0x0337a70e: 9903      ldr     r1, [sp, #12]
      0x0337a710: 9a04      ldr     r2, [sp, #16]
      0x0337a712: 9b05      ldr     r3, [sp, #20]
      0x0337a714: e7ea      b       -44 (0x0337a6ec)

这段代码从0x0337a702-0x0337a712 是调用pTestSuspend入口的,调用入口不需要参数,所以前面它保存了r1, r2, r3三个参数,调用后又恢复了r1,r2,r3参数。至于要保存那些参数,根据实际情况定。
在最后一条语句,则是返回到调用现场,继续运行。这里它没有使用blx这样的调用,而是直接用b指令,目的应该是为了尽量减少寄存器的使用。

了解dex各类指令以及异常的实现方法

接下来,我们了解下各类dex指令的实现。这些指令的实现都和class、object、method、field的实现结构密切相关,但是,在我们具体了解这些结构的具体内容之前,我们先了解下ART是怎样使用它们的,就更容易理解这些结构为什么被设计成那种样子。

上文提到了invoke的实现,这里我们就不再解释

dex指令的实现

const-string

boot内的字符串查找

dex代码:

0x001e: 1b02 5501 0000            | const-string/jumbo v2, " doesn't implement Cloneable" // string@341

对应的机器码反汇编后是

      0x02d7a184: 4a1f      ldr     r2, [pc, #124]  ; 0x6fbf9ef0                                                                     
      0x02d7a186: 4601      mov     r1, r0   
      0x02d7a188: 4607      mov     r7, r0   
      0x02d7a18a: 4690      mov     r8, r2   
      0x02d7a18c: 6808      ldr     r0, [r1, #0] 

其中0x02d7a184就是加载字符串地址的代码。可以看到,读取pc偏移124的值(0x6fbf93f0) 即时字符串对象的地址。
pc + 124得到的值是 0x2D7A202 , 让他对齐到4字节后,就是地址 0x2D7A204:

      0x02d7a204: 9ef0      ldr     r6, [sp, #960]
      0x02d7a206: 6fbf      ldr     r7, [r7, #120] 

注意这里0x2d7a204位置不是代码,而是数据,但是反汇编器没有识别,仍旧当作代码来解析。我们看到,204处是9ef0, 206处是6fbf,合在一起,正是一个4字节地址:0x6fbf93f0 (因为arm是小端)。
这个地址是一个绝对地址,它实际指向的是boot.art映射的内存。我摘取的代码来自boot.oat。因为art会把boot.art加载到一个固定地址,所以,这里的代码可以这样处理。
另外需要注意的是,这里得到的地址,并不是字符串的地址,而是java String对象的地址。因为C语言里面的字符串是字符数组,是无法让java语言处理的。

应用的字符串查找方法

如果是应用程序的oat文件,没有对应的art映射文件,应该如何处理呢?
实际上,ART是通过bss段的数据来实现的。
为了说明这个问题,我们下载一个应用的oat看看。

adb pull /data/dalvik-cache/arm/system@app@Bluetooth@Bluetooth.apk@classes.dex
oatdump --oat-file=system@app@Bluetooth@Bluetooth.apk@classes.dex > bluetooth.txt

首先,我用readelf -a system@app@[email protected]@classes.dex 看看这个文件的结构(只摘抄关键的部分):

节头:
  [Nr] Name              Type            Addr     Off    Size   ES Flg Lk Inf Al
.....
  [ 3] .bss              NOBITS          00f0b000 000000 06b354 00   A  0   0 4096
....
Symbol table '.dynsym' contains 6 entries:
   Num:    Value  Size Type    Bind   Vis      Ndx Name
     0: 00000000     0 NOTYPE  LOCAL  DEFAULT  UND 
     1: 00001000 0x8f3000 OBJECT  GLOBAL DEFAULT    1 oatdata
     2: 008f4000 0x6165a0 OBJECT  GLOBAL DEFAULT    2 oatexec
     3: 00f0a59c     4 OBJECT  GLOBAL DEFAULT    2 oatlastword
     4: 00f0b000 0x6b354 OBJECT  GLOBAL DEFAULT    3 oatbss
     5: 00f76350     4 OBJECT  GLOBAL DEFAULT    3 oatbsslastword

请注意下,“节头”中第3条 .bss,起始位置是 00f0b000,大小是06354, 对应”Symbol table ‘.dynsym’ 中的第4条,即“oatbss”部分。
bss段是用来指定没有初始值的全局和静态变量的,在文件中没有分配空间,但是加载到内存中时,需要分配空间。程序启动时,系统会自动清零。
oatbss段,就被ART用来存放各种全局变量和静态变量,其中就包括这些常量字符串对象。
经过计算,oatbss的范围是 0x00f0b000-0x00f76354 (最后4字节即时oatbsslastword)

下面,我们在看看一个加载的例子。首先,看一下dex的写法:

0x0005: 1b08 e74f 0000            | const-string/jumbo v8, "Ra" // string@20455

这条指令,是加载dex文件中,索引为20455的字符串。
的对应的汇编代码:

      0x008f4366: f6456086  movw    r0, #24198
      0x008f436a: f2c00065  movt    r0, #101
      0x008f436e: 4478      add     r0, pc  
      0x008f4370: 900b      str     r0, [sp, #44]
      0x008f4372: 6802      ldr     r2, [r0, #0]
      0x008f4374: 2a00      cmp     r2, #0  
      0x008f4376: f00081f8  beq.w   +1008 (0x008f476a)                                                                               
      0x008f437a: 9206      str     r2, [sp, #24]

movw是将立即数放入寄存器低16位,movt是放入到高16位。故此,前两条语句,使 r0的值为 0x655e86。
第三条语句含义为r0 = r0 + pc,此时pc的值0x008f4372, 这时,r0的值为 0xF4A1F8。该值正好在 0x00f0b000-0x00f76354 范围内,即是oatbss内部的内容。所以,这是取一个静态的字符串对象的地址。
第6,7条指令(cmp r2, #0; beq.w +1008 ) 则是判断对象是否初始化,没有初始化,就去加载这个字符串。加载字符串的地址是 0x008f476a:

      0x008f476a: 900e      str     r0, [sp, #56]
      0x008f476c: f64470e7  movw    r0, #20455
      0x008f4770: f8d9e154  ldr.w   lr, [r9, #340]  ; pResolveString
      0x008f4774: 47f0      blx     lr
      0x008f4776: 4602      mov     r2, r0  
      0x008f4778: 980e      ldr     r0, [sp, #56]
      0x008f477a: e5fe      b       -1028 (0x008f437a)  

首先,ART保存了r0寄存器(因为r0要作为参数和返回值),然后从pThread (r9) 中取得pResolveString的地址,然后调用。得到的结果,保存在r2中,然后恢复r0值,在跳转到回去,继续执行。

ART为了避免寄存器被污染,所以为每次加载字符串的地方都生成了这种辅助代码。

const-class

根据各种情况,可以分为多种实现

method 加载本身所在类

ArtMethod第一个成员就是declaring_class, 因此这种情况下,直接从ArtMethod指针中获取就可以。比如下面的例子

  5: java.lang.Object java.text.AttributedCharacterIterator$Attribute.readResolve() (dex_method_idx=9453)
    DEX CODE:
      ....
      0x0004: 1c02 8c03                 | const-class v2, java.text.AttributedCharacterIterator$Attribute // type@908 

要加载的就是method所在的类
对应的机器码是

    CODE: (code_offset=0x02d7c6dd size_offset=0x02d7c6d8 size=240)...
...
      0x02d7c6e4: e92d45e0  push    {r5, r6, r7, r8, r10, lr} 
      0x02d7c6e8: b086      sub     sp, sp, #24
      0x02d7c6ea: 9000      str     r0, [sp, #0] 
      0x02d7c6ec: f8b9c000  ldrh.w  r12, [r9, #0]  ; state_and_flags
      0x02d7c6f0: f1bc0f00  cmp.w   r12, #0  
      0x02d7c6f4: d158      bne     +176 (0x02d7c7a8)
      0x02d7c6f6: 4605      mov     r5, r0   
...
      0x02d7c706: 682f      ldr     r7, [r5, #0]                                                                                     
      0x02d7c708: 42b8      cmp     r0, r7   

我保留了入口部分的代码,可以看到,r0是入参,ArtMethod指针,首先r0被保存到r5,然后,取r5 + 0偏移位置的值(即delcaring_class_),就获得了class的地址。

其他情况下取得class的方法

如果要取得一个和当前method没有任何关系的class,就要用到ArtMethod中一个非常重要的成员: dex_cache_resolved_types_ 中。在arm平台,它的偏移是24
比如,下面的例子:

0x0010: 1c02 e400                 | const-class v2, java.lang.Enum // type@228

java.lang.Enum类与当前的method没有任何关联,它的获取是通过
art_method->dex_cache_resolved_types_[228] 获取的。下面的代码如下:(请注意注释)

      0x02da522a: 69b9      ldr     r1, [r7, #24] //r7 是ArtMethod指针,即当前函数, 将 r1 = art_method->dex_cache_resolved_types_                                               
      0x02da522c: f8d11390  ldr.w   r1, [r1, #912]  //取 r1[912]。  912 = 228 * 4
      0x02da5230: 9104      str     r1, [sp, #16]
      0x02da5232: 4288      cmp     r0, r1

一个class地址占用4字节(即使是64位的架构,class也是占用4字节),所以228 * 4 = 912,即是 偏移地址。

需要注意的是,上面例子,我给出的是java.lang.Enum,这是一个基础类,所以可以认为这个类一定是被解析过的,可以直接使用的,如果加载一个任意类,那么ART就不能保证这个类一定被解析过,所以需要检查一下,如果没有加载,就会先去加载。比如下面的例子

0x008c: 1c08 5001                 | const-class v8, android.net.dhcp.DhcpPacket$ParseException // type@336

对应的机器码:

      0x00904da4: f8db1018  ldr.w   r1, [r11, #24]
      0x00904da8: f8d11540  ldr.w   r1, [r1, #1344]
      0x00904dac: 2900      cmp     r1, #0  
      0x00904dae: f0008165  beq.w   +714 (0x0090507c)
      0x00904db2: 9105      str     r1, [sp, #20]

这里,r11是ArtMethod*指针。取得对象后,会检测一下是否为空(0),如果为空,就会跳转到 0x0090507c:

      0x0090507c: f44f70a8  mov.w   r0, #336
      0x00905080: f8d9e150  ldr.w   lr, [r9, #336]  ; pInitializeType
      0x00905084: 47f0      blx     lr
      0x00905086: 4601      mov     r1, r0  
      0x00905088: e693      b       -730 (0x00904db2)

这里,r9就是pThread指针,调用pInitiliazeType函数,参数是class的索引:336。初始化成功后,就再跳回去继续执行。

new-instance

在dex中,new一个对象,被分拆成两个指令:new-instance和invoke-direct。即先创建对象,然后在调用构造函数。我们重点关注的是创建对象
例如

0x0006: 2200 6d01                 | new-instance v0, android.net.metrics.IpConnectivityLog // type@365
      0x00905fe4: 9900      ldr     r1, [sp, #0]
      0x00905fe6: f240106d  movw    r0, #365
      0x00905fea: f8d9e11c  ldr.w   lr, [r9, #284]  ; pAllocObject
      0x00905fee: 47f0      blx     lr

r9是pThread指针,调用pThread->pAllocObject。其中,参数r0是class的index, 参数r1是调用者的ArtMethod。
因为ArtMethod中包含很多信息,所以这个信息是很重要的。
基本上所有的实现都是这样的。

get/put instance field

ART会将所有的field转换为它们在object中的偏移,所以field的存取相对简单很多。

iget

比如:

0x0018: 5432 6b01                 | iget-object v2, v3, Landroid/net/DhcpResults; android.net.dhcp.DhcpClient.mDhcpLease // field@363

它的含义是 v2 = v3.mDhcpLease。
对应的实现

      0x00906872: 6b2a      ldr     r2, [r5, #48]
      0x00906874: 9207      str     r2, [sp, #28]

r5 即对应的v3寄存器对象,#48就是field mDhcpLease在v3中的偏移。v2对应的sp + 28的位置(因为寄存器不够用了),所以,它先被加载到r2寄存器,然后再存入到sp上。
之所以用r2寄存器,是因为r2寄存器马上要作为参数传递给即将调用的函数。这是ART一个优化措施。

iput

iput的实现与iget的实现非常类似,查找field的方法都是一样的。但是iput-object有一个不同的地方:iput-object要同步card-table。
card-table是一个GC相关的数据。简单来说,card-table是记录object引用关系的。
iput-object会导致对象的引用关系发生变化,这时,ART就要更新对应的card-table,让GC能够知道那块内存变脏了,需要重新查找。
直接看机器码:

      0x00906c52: 65fe      str     r6, [r7, #92]
      0x00906c54: f8d90080  ldr.w   r0, [r9, #128]  ; card_table
      0x00906c58: 09f9      lsrs    r1, r7, #7
      0x00906c5a: 5440      strb    r0, [r0, r1]

第一条指令就是实现iput-object的: r7.field = r6。92就是field的offset
剩下的语句,翻译成c伪代码就是:

card_table = pThread->card_table;
card_table[r7 >> 7] = card_table&0xff;

ART中,card_table不是位,而是以字节为单位管理一块内存,一个字节对应128字节的数据,所以r7 >> 7 后就能得到它的索引。如果对应内存脏了,那么对应的字节就会设置为一个特定值。
这个特定值正好是card_table地址的最低字节。
ART这样设计自然是为了效率。

get/put static field

sget, sput的实现与iget, iput非常类似,只是object需要换成class的指针。ART的class对象后面同样放置了static field的值,而且是sget,sput都直接使用偏移来访问。同样的sput-object指令也会更新card-table,方法也是一样的。有兴趣的读者可以自己查阅。

你可能感兴趣的:(ART揭秘,ART深入浅出,android)