如果遇到bl32 panic ，如果能明显感觉到错误的发生位置，可以使用加EMSG 打印的方式debug
但是遇到压测的时候发生的panic， 这样是低效的，而且加上log还会影响时序，影响压测结果。
下面给出一个终极debug 方式，这样的判断panic 发生的函数位置， 百试不爽。
举例：
[ 266.388550][0 T45 ..] [TEE] E/TC:1 00 Core data-abort at address 0x0 (translation fault) [ 266.396969][0 T45 ..] [TEE] E/TC:1 00 fsr 0x00000805 ttbr0 0x053bc06a ttbr1 0x0539006a cidr 0x4 [ 266.406166][0 T45 ..] [TEE] E/TC:1 00 cpu #1 cpsr 0x00000133 [ 266.413017][0 T45 ..] [TEE] E/TC:1 00 r0 0x00000000 r4 0x00040000 r8 0x0025f2f8 r12 0xfffbb5cc [ 266.422803][0 T45 ..] [TEE] E/TC:1 00 r1 0x00000000 r5 0x00000000 r9 0x00197381 sp 0x6b2726e8 [ 266.432629][0 T45 ..] [TEE] E/TC:1 00 r2 0x00000010 r6 0x00003fff r10 0x6b27275c lr 0x6b1baf97 [ 266.442420][0 T45 ..] [TEE] E/TC:1 00 r3 0x00000000 r7 0x00040010 r11 0x00000000 pc 0x6b1edfac [ 266.452131][0 T45 ..] [TEE] E/TC:1 00 TEE load address @ 0x6b1b0000 [ 266.458677][0 T45 ..] [TEE] E/TC:1 00 Call stack: [ 266.463541][0 T45 ..] [TEE] E/TC:1 00 0x6b1edfac [ 266.468452][0 T45 ..] [TEE] E/TC:1 00 0x6b1baf97 [ 266.473422][0 T45 ..] [TEE] E/TC:1 00 0x6b1bde0d [ 266.478486][0 T45 ..] [TEE] E/TC:1 00 0x6b1efbbb [ 266.483302][0 T45 ..] [TEE] E/TC:1 00 0x6b1bb81b [ 266.488213][0 T45 ..] [TEE] E/TC:1 00 0x6b1ba324
bl32 会在panic的时候自动print 函数的调用栈，我们可以根据调用栈追查api
可以知道最近的两个api是 0x6b1baf97 , 0x6b1edfac
然后根据 TEE load address @ 0x6b1b0000为基址算出 偏移量，为 0xaf97 和 0x3dfac
我们找到 0xaf97 属于secmon_storage_shm_unlock 函数范围之内
找到0x3dfac 属于memset.c 第110 行发生panic， 发现他是一个memset 函数
于是知道 secmon_storage_shm_unlock 内部调用了 memset api的时候发生了panic
这样直接定位出了crash的位置
标签：00,..,TEE,T45,opteeos,panic,TC From： https://www.cnblogs.com/coversky/p/18191681