Android异常分析基础之 --- APCS(ARM程序调用标准) --- (一) --- AArch64的体系架构

很多朋友在分析android tombstone异常的时候,面对一堆堆的寄存器数据,堆栈,往往不知道应该看些什么,怎么看。

今天,我们先从异常分析的基础开始,一步步的由函数调用标准,寄存器保存,堆栈结构,操作系统signal等来说明,具体描述到底对tombstone文件,应该如何理解,并获取其中有重要价值的信息。并由此得出我们的分析结论。

首先, 我们从理解ARM程序调用标准开始进入我们的异常分析。(以下以ARMv8的AArch64架构的APCS标准为例进行说明,关于ARMv7版本以下由于架构不同,这里就不再做具体说明了)

第一步: 思考以下,我们在代码实现的时候,往往由C或C++语言参考一个标准的程序调用。如下所示:

int function_callee(int a, double b, char c, short d)
{
    printf("%d, %f, %c, %d", a, b, c, d);
    return 0;
}

int function_caller()
{
    int aa = 3;
    double bb = 6.6;
    char cc = 'x';
    short dd = 6;
    
    function_callee(aa, bb, cc, dd);
}

 那么,在真实的执行环境中,这些参数应该是如何传递的呢? 中间会用到那些内存区域? 这些变量是如何排布的?为什么有时候我们会遇到莫名其妙的我们的数据被踩踏的问题?

其实,这些就涉及到在二进制层面,程序是如何传递,控制整个程序的执行和转换的流程。也就是我们常说的 ABI (应用程序二进制接口)。 而APCS就是ARM的ABI中的一个部分,用来定义在二进制层面应用程序的函数之间如何控制,传递参数,以及怎么样使调用流程进行跳转的标准。

本节,我们先简单介绍ARMv8的AArch64体系架构,以帮助我们后续更好的理解APCS的实现

 

ARM的体系架构

    特点

    ARM是一套精简指令集架构(RISC)体系下的CPU架构。对应每个PE(处理单元,可简单的理解为一个CPU核心), 她具有如下的几个特点:

    1: 有一组很大统一的寄存器组

    2: load / store 架构,数据操作只能在寄存器中进行,无法直接对内存数据进行数据操作

    3: 简化的地址模式, 所有的 load / store地址都来源自寄存器和指令域。

    4: ARM支持SIMD(单指令多数据)和浮点运算指令。

    5: AArch64向前兼容支持AArch32的指令操作

 

    架构

    1: AArch64提供了31个64位通用寄存器, 从X0 到 X30, 其中, X30用作程序链接寄存器(LR)

    2: AArch64提供了一个程序计数寄存器(PC), 若干堆栈寄存器(SP),和若干异常链接寄存器(ELR) (这里的若干指的是,CPU的在不同的执行状态下,会使用不同的寄存器,但这些寄存器不同时可见)

    3: AArch64提供了32个128位用来做 SIMD 和 浮点运算的寄存器

    4: AArch64定义了一套单独的指令集

    5: AArch64定义了高达四层的异常模式, 从EL0 到EL3, 来提供不同的CPU特权等级

    6: AArch64支持高达64位的虚拟地址寻址

    7: AArch64定义了一些处理器PE状态,由PSTATE控制

    8: 定义了一组系统寄存器,使用的时候由这些系统寄存器的特权等级作为后缀来访问 (所谓系统寄存器,是用来提供架构中的控制和状态信息的寄存器,涉及到中断控制,内存映射等等)

 

 

 

 

上一篇:Spring Boot demo系列(五):Docker部署


下一篇:1+x LVM