破获ARM64位CPU下linux crash要案之神技能：手动恢复函数调用栈（一）
情况是在不断地变化，要使自己的思想适应新的情况，就得学习。
——毛爷爷
1案情引言
前不久瓶子哥的一位刚入职的同事小马在调试基于三星S6手机平台的7420 SoC（ARM64位处理器）芯片Android驱动的时候遇到了一个linux crash问题，但是panic出来后没有打印出backtrace（函数的调用关系），作为新手的他看到如下的界面，我想大概率都是懵逼的状态吧
为了彰显我老司机的地位，也为了刷一波存在感，后来瓶子哥帮忙他分析了下ARM64 linux的函数调用关系以及AAPCS64规则，通过手动获取调用堆栈的方式很快定位和解决了此问题。瞬间小马向我投来了异样的眼神，偶想这下应该就直接奠定了我“大婶”的地位把，不过瓶子哥我怎么感觉后背有种瑟瑟发凉的感觉呢？
对于这个问题我又深思了下，然后意识到，早在2013年苹果发布了iPhone 5s，其做为第一款应用了ARMv8架构的64位处理器的手机以来，各大手机厂商也在64位处理器的道路上摩拳擦掌，你苹果既然带头弄了个64位SoC，那么大家也就弄64位吧，不然外行以为64位厉害（似乎苹果总能在某些方面引领科技潮流啊），随后高通发布了骁龙410 64位SoC，MTK 的MT6732，华为的麒麟620等64位处理器相继现身。
现在的移动AP处理器来说基本都已经鸟枪换炮成64位CPU了。似乎手机厂商在搞PPT的时候，如果不宣称自己的处理器是64位的话，码农门表示他都没法混下去了。但不管厂商们上不上64位处理器，我们码农的生活还是要继续的，瓶子哥的课还是要继续的。
言归正传，对于这类没有正常显示backtrace的ARM64位体系结构下的linux crash case，该如何分析解决，如何能够有一套行之有效的破案手法呢？
2概述
资深的码农们都知道，如果要定位分析PANIC/OOPS等这类crash问题，有如下堆栈的backtrace调用关系的话无疑对于我们快速定位和分析异常问题有很大的帮助（当然那种我等小白一眼就能发现的错误以及本身打印出了正常的backtrace的话，我们当然不需要恢复堆栈，大家直接可以洗洗睡了哈）。
那么问题来了，对于ARM64位SoC来说，开发过程中遇到了linux crash后没有打印出backtrace的话，该如何手动恢复呢？是否还是和32位CPU体系结构下相同的恢复方法呢？答案是否定的。
根据ARM官方的手册，对于AArch64的AAPCS有别于ARM的AAPCS，因此堆栈的组织调用方式也有差异，所以对于在64bit平台上遇到的没有backtrace的crash问题，我们需要根据AAPCS64的规则，找出函数在调用的过程中，相关的参数，寄存器出入栈规律来手动恢复堆栈。
所谓磨刀不误砍柴工，心急吃不了热豆腐，那么问题来了，“狗蛋，你知道对于今天我们要讲的这个神技能，我们都需要掌握哪些基础理论知识才能够愉快的实践呢？”
“呃，这个嘛，就是，那个，恩，###@！#￥%……%&*……，老湿，狗蛋我好像不知道耶，但是...”
“好吧，看你们大家一脸懵逼的样子，那老湿我还是继续吧，前面说的这些AArch64，AAPCS64，Backtrace等名词，大家不懂没有关系，这节课就是针对这些知识点为大家扫盲及答疑解惑的。”
“狗蛋，你要好好的做好笔记啊！做好笔记！做好笔记！重要的事情说3遍。你们明年升职加薪，出去 装X的神技能就靠它咯，不管你信不信，作为老司机的的我来说，反正我是信了，哎呀呀，是不是有点鸡冻呀！”
Ok，言归正传，everybody，码农大讲坛正式开始上课，今天针对这个ARM64位体系构下调试linux crash问题，如果没有打印出函数的调用堆栈关系，要进行手动栈回溯的话，需要大家掌握以下知识点：
1. 栈回溯的认知
2. 基于ARM64 AAPCS64栈帧的组织方式
3. 神兵利器之Crash工具使用
4. 庖丁解牛之实操手动恢复堆栈
（未完待续，干货即将奉上）