info proc mappings是唯一可靠方式，它列出进程全部虚拟内存映射区域及其起止地址、权限和来源，需在程序运行或暂停时执行，通过人工比对地址是否落在某行范围内来确定所属内存段。
用 info proc mappings 查看地址所属内存段
直接查地址归属，最可靠的方式是让 GDB 告诉你当前进程的完整内存布局，再人工比对地址范围。GDB 本身没有「查某地址属于哪段」的一键命令，但 info proc mappings（或简写 i proc m）能列出所有映射区域及其起止地址、权限和来源，这是唯一可信赖的依据。
- 必须在程序已运行（
run或停在断点后）状态下执行，否则会报错Not supported on this target - 输出中每行格式类似：
0x0000555555554000 0x0000555555555000 r-xp /path/to/executable，其中首尾两列是虚拟地址范围 - 地址落在哪一行的范围内，就属于那一段：例如
.text段通常对应r-xp（可读可执行）且来源为可执行文件；.data或.bss对应rw-p区域；堆（heap）和栈（stack）也会明确标注或可通过特征识别（如栈段常含[stack]字样）
info files 能看到加载节区（section）信息，但不反映运行时映射
info files 显示的是 ELF 文件静态结构：各节区（如 .text、.rodata、.data）的偏移、大小和属性。但它不告诉你这些节区在进程地址空间里被映射到哪——因为链接器可能合并、对齐、丢弃某些节区，实际映射以 info proc mappings 为准。
- 比如
.text和.rodata常被合并进同一个r-xp段；.data和.bss合并进rw-p段 -
info files中的地址是文件内偏移（File offset），不是运行时虚拟地址（VMA），不能直接用于判断段归属 - 适合用来确认符号是否在预期节区里（如函数地址是否落在
.text范围内），但不能替代运行时映射查询
用 maint info sections 辅助验证节区 VMA
如果你需要知道某个节区（如 .text）在内存中的实际起始地址，maint info sections 会显示每个节区的 VMA（Virtual Memory Address）和 LMA（Load Memory Address），这比 info files 更接近运行时视图。
- 输出示例：
0x0000000000401000->0x0000000000402000 at 0x0000000000001000: .text ALLOC LOAD READONLY CODE - 第一组地址（
0x0000000000401000->0x0000000000402000）就是该节区在进程中的虚拟地址范围，可用于与info proc mappings的结果交叉验证 - 注意：
maint命令属于维护模式，部分 GDB 版本需启用（如启动时加--maintenance），且输出格式较原始，不适合初学者直接依赖
为什么不用 vmmap 或外部工具？
一些用户会想到用 /proc/PID/maps 配合 cat /proc/$(pidof yourprog)/maps，效果等同于 info proc mappings，但多了一层 shell 切换。GDB 内置命令更直接，且保证查看的是当前调试会话对应的进程状态。另外，像 readelf -S 或 objdump -h 只能看二进制静态结构，无法反映 ASLR、mmap 分配、堆增长等运行时变化——真正决定「某地址属于哪段」的，永远是进程实际的内存映射，而不是编译时的节区定义。
容易忽略的一点是：同一地址在不同运行时刻可能属于不同段（比如堆顶移动后，某地址从「未映射」变成「heap」），所以必须在目标状态（如崩溃点）下执行 info proc mappings 才有意义。
