arm-linux相关-镜像/虚拟内存

lei7143

已于 2022-07-08 14:56:55 修改

阅读量924

点赞数 1

分类专栏： android-linux 文章标签： linux 运维服务器

于 2022-06-15 20:40:13 首次发布

本文链接：https://blog.csdn.net/lei7143/article/details/125304187

版权

android-linux 专栏收录该内容

20 篇文章 1 订阅

订阅专栏

ARM之镜像文件/可执行文件/ELF文件/对象文件

异常堆栈地址转换

ARM之镜像文件/可执行文件/ELF文件/对象文件

ARM之镜像文件/可执行文件/ELF文件/对象文件 - 程序员大本营

https://online.mediatek.com/QuickStart/QS00038#QSS00309

类型
(1). 定义（目标文件格式主要三种）
    可重定向文件(Relocatable file): 文件保存着代码和适当的数据，用来和其他的目标文件一起来创建一个可执行文件或者是一个共享目标文件。由编译器和汇编器生成，将由链接器处理。
    可执行文件(Executable File): 文件保存着一个用来执行的程序；该文件指出了exec如何来创建程序进程映象。所有重定向和符号都解析完成了，如果存在共享库的链接，那么将在运行时解析。
    共享目标文件(Shared object file): 就是所谓的共享库。文件保存着代码和合适的数据，用来被下面的两个链接器链接。第一个是连接编辑器[ld]，可以和其他的可重定向和共享目标文件来创建其他的目标文件。第二个是动态链接器，联合一个可执行文件和其他的共享目标文件来创建一个进程映象。包含链接时所需的符号信息和运行时所需的代码。

通俗讲：可重定向文件指一段功能代码（.o），这些功能代码，是为了和其它的目标文件组合成新的目标文件(.so)，或者和其它的目标文件组合成可执行文件(.out)；

ELF格式
目标文件既要参与程序链接又要参与程序执行。出于方便性和效率考虑，目标文件格式提供了两种并行视图，分别反映了这些活动的不同需求。编译器，链接器把它看作是sections的集合，loader把它看作是segments的集合：

链接时的视图时通过section header table 来描述

加载执行时通过program header table 来描述

加载执行的segment 是由一个或多个链接时Section 组成，segment 加载到ram 执行就对应这ZI、RW、RO 程序区域

说到合并后的段（Segment）和合并之前的段（Section），虽然中文叫法相同，但对于英文称谓是不同的。合并后的段是 Segment，是程序装载时的概念，合并之前的段是 Section，是程序链接时的概念，需要加以区分。系统按照 Segment 进行装载映射可执行文件而不是 Section。

参见（Linux 进程虚拟地址空间布局 - 云+社区 - 腾讯云）

虚拟内存的大小是由CPU地址长度确定的。

虚存的实际容量由CPU的地址长和外存的容量决定，当CPU的地址长度能表示的大小远远大于外存容量时，虚存的实际容量为内存和外存容量之和；当外存容量远大于CPU字长能表示的大小时，虚存的实际容量由CPU字长决定。一般情况下，CPU的地址长度能表示的大小都大于外存容量。

虚存容量不是无限的，最大容量受内存和外存可利用的总容量限制，虚存实际容量受计算机总线地址结构限制。

异常堆栈地址转换

<5>[123651.375860]-(5)[270:hang_detect]Kernel Offset: 0x286a000000 from 0xffffff8008000000
<5>[123651.375878]-(5)[270:hang_detect]PHYS_OFFSET: 0xffffffdb80000000

Binder:1532_20 S 91381.737394 4055 100315 60238 0x40404140 0x4000800 1532 123606767847629
<ffffffa8720881f0> __switch_to+0x144/0x170 =>pc
<ffffffa873361284> __schedule+0x89c/0x9d0
<ffffffa87336142c> schedule+0x74/0x98
<ffffffa87217cabc> futex_wait_queue_me+0xd8/0x134
<ffffffa872179cf4> futex_wait+0x120/0x2d4
<ffffffa8721783f4> do_futex+0x110/0x18f0
<ffffffa87217bb4c> __arm64_sys_futex+0x150/0x1d4
<ffffffa8720a4758> invoke_syscall+0x64/0x138
<ffffffa872098ea4> el0_svc_common+0x84/0x12c
<ffffffa872098e04> el0_svc_handler+0x64/0x80
<ffffffa872083d08> el0_svc+0x8/0xc
<ffffffffffffffff> 0xffffffffffffffff

Binder:1532_20 sysTid=4055, pid=1532
#0 pc 7710f78220 =》pc
#1 pc 766e074b4c
#2 pc 766e1755a8
#3 pc 766e174ba0
#4 pc 766e555af4
#5 pc 766e0d2d7c

对应内核空间调用栈：

addr_link = pc - kaslr_offset （0x286a000000）

prebuilts/clang/host/linux-x86/clang-r416183b/bin/llvm-addr2line -C -f -e vmlinux addr_link

ko 模块

mtk_pq_enhance_parse_dts+0x40/0x1c8 [mtk_pq]
=> SYMBOL_NAME+ERROR_ADDR/total_size [module]

1. 找到沒有strip過的.ko or .o的module
$ cd out/target/product/XX/KERNEL_MODULES/
$ cd out/target/product/XX/obj/KERNEL_OBJ/

2. nm or objdump
nm -o xxx.ko | grep -in "SYMBOL_NAME"
objdump -S XXX.ko | grep -in "SYMBOL_NAME"
==> 得到symbol line
ex: mtk_pq.ko:0000000000028c T SYMBOL_NAME

3. symbol line + ERROR_ADDR = $TARGET_ADDR

4. addr2line -e xxx.o $TARGET_ADDR

对应用户空间so 库

766e000000-766e5f7000 r-xp 00200000 /apex/com.android.art/lib64/libart.so
767045f000-76704b4000 r-xp 0002e000 /apex/com.android.art/lib64/libunwindstack.so
767051e000-7670522000 r-xp 00003000 /system/lib64/libtombstoned_client.so
767054c000-7670551000 r-xp 00004000 /system/lib64/libartpalette-system.so

1、跟据pc ，找到对应pc 对应的so 库

2、pc - start_lib ;即pc 跟 so 库开始加载位置偏移

3、readelf -l -W XX.so

Type Offset VirtAddr PhysAddr FileSiz MemSiz Flg Align
PHDR 0x000040 0x0000000000000040 0x0000000000000040 0x000230 0x000230 R 0x8
LOAD 0x000000 0x0000000000000000 0x0000000000000000 0x16ac2c 0x16ac2c R 0x200000
LOAD 0x200000 0x0000000000200000 0x0000000000200000 0x5fd4a0 0x5fd4a0 R E 0x200000

Flg 对应R E 行对应的offset

4、addr_link = pc - start_lib + offset

addr2line -C -f -e XX.so addr_link

addr2line 转换没有对应的代码行

file XX.so 库可以查看XX.so 库是否被strip 了，另外 llvm-readelf -S XX.so 库查看对应段，一般strip 了，会去掉.symtab

1. 编译的时候，没有调试符号信息，如-g参数

2. 编译出so库之后，被strip去掉了符号和段信息