Linux下通过解析/proc/self/maps中r-xp权限且匹配可执行文件路径的行，取其地址范围起始值即为加载基址；Windows下调用GetModuleHandle(NULL)直接获取。
Linux下用/proc/self/maps定位主模块基址
Linux没有直接暴露“当前程序符号表基址”的API，但可从/proc/self/maps解析出可执行文件的加载起始地址，这个地址就是ELF头部所在位置，也是符号表（.symtab、.dynsym）在内存中相对偏移的基准点。
常见错误是直接读/proc/self/exe链接再mmap——这得到的是文件内容，不是运行时实际加载地址；而maps里第一行通常对应主可执行映射，且标记为r-xp（可读可执行），其起始地址即为基址。
- 逐行读取
/proc/self/maps，找含r-xp且路径结尾为可执行文件名（如/path/to/a.out）的那一行 - 提取首字段（形如
555555554000-555555558000），555555554000就是基址 - 注意：ASLR开启时每次运行基址不同；禁用ASLR（
echo 0 | sudo tee /proc/sys/kernel/randomize_va_space）仅用于调试，不可用于生产
Windows下用GetModuleHandle(NULL)获取主模块基址
Windows更直接：GetModuleHandle(NULL)返回当前进程主模块（即exe本身）的HMODULE，本质就是PE头部在内存中的地址，也就是符号表（IMAGE_SYMBOL等结构）的加载基址。
容易踩的坑是误用GetModuleHandle(L"kernel32.dll")之类——那是DLL基址，和主程序符号表无关；另外，如果程序是DLL注入或以DLL方式加载，NULL参数可能不指向预期模块。
立即学习“C++免费学习笔记（深入）”；
组合式C++代码评审方案，融合静态分析、AI推理、多轮迭代评审和C++专项检查，适用于PR审查、增量代码审查、全项目评审和代码质量评分，触发词包括review cpp、cpp代码评审、C++review、代码审查。
-
HMODULE hMod = GetModuleHandle(NULL);返回值即为基址（类型是HMODULE，可安全转为uintptr_t） - 若需验证是否有效，可检查该地址处是否为有效的PE签名（前两个字节是否为
'M' 'Z'） - 注意：此基址是PE头地址，符号表（.pdb或IMAGE_DEBUG_DIRECTORY）需按PE结构偏移计算，不是直接加固定偏移
符号表本身不在内存中常驻，别指望运行时直接读.symtab
ELF的.symtab节默认不加载到内存（只保留在磁盘文件中），.dynsym才加载，但只含动态链接所需符号；Windows的COFF符号表通常存于独立PDB文件，运行时并不映射进进程空间。
这意味着：即使你拿到基址，也不能直接用指针访问符号表——它根本不在那里。想做符号解析，得自己解析磁盘上的二进制文件，或调用libbfd/libdwarf（Linux）或dbghelp.dll（Windows）这类工具库。
- Linux下可用
objdump -t ./a.out确认.symtab是否在文件中，再用readelf -S ./a.out查其文件偏移，结合基址+段映射关系换算内存地址（但前提是该节被mmap进来了） - Windows下必须用
SymInitialize+SymLoadModule64加载PDB，才能通过SymEnumSymbols查符号——基址只是起点，不是终点 - 调试器（如gdb/lldb）能读符号，是因为它们主动加载了磁盘文件并解析，不是靠运行时内存布局
跨平台代码里别硬编码基址用途，先明确你要干什么
很多人问“获取基址”其实是想实现函数hook、堆栈回溯或符号化崩溃地址——这些场景对“基址”的定义和使用方式完全不同。
比如：回溯时用backtrace得到的是相对于基址的偏移，但glibc内部已自动做了基址修正；而手动hook某个函数，则需要先用GetProcAddress或dlsym拿到地址，再减去基址得偏移，才能写入patch——但这个偏移依赖于编译时的符号可见性（-fvisibility=hidden会让很多符号消失）。
- 确定目标：是打印符号名？打补丁？还是生成core dump分析用的地址映射？每种需求对应的“基址”来源和后续处理都不同
- 避免把“加载地址”和“符号表地址”混为一谈：前者是物理内存起点，后者是逻辑数据结构位置，中间隔着节头表、重定位、甚至压缩（如stripped binary无.symtab）
- 最稳妥的做法：用标准调试接口（
libdw/dbghelp）代替手撕解析，尤其当面对strip过的发布版二进制时
