为何Linux内核符号elf_core_dump存在两个内存地址？

针对你在AArch64架构4.20版本自定义编译内核中遇到的elf_core_dump符号对应两个内存地址的问题，常见原因如下：

• 兼容模式（COMPAT）导致的函数多实例化
  AArch64内核开启CONFIG_COMPAT选项时，会同时支持64位和32位用户态程序。此时内核会为两种程序分别实例化一套core dump处理逻辑，elf_core_dump作为核心处理函数，会生成64位和32位两个版本的实例，对应不同内存地址。你可以检查内核配置中CONFIG_COMPAT是否开启，这是该场景下最常见的原因。

• 代码重复定义或条件编译分支冲突
  若你修改过内核代码或配置，可能导致elf_core_dump在多个编译单元中被定义：比如在不同的条件编译分支（如针对不同内存模型、调试选项）中重复实现了该函数，且当前配置同时触发了这些分支。可以通过grep -r "elf_core_dump" --include="*.c" <内核源码目录>搜索代码，确认是否存在多个定义点。

• 链接器特殊处理或配置问题
  内核编译时的链接脚本（如arch/arm64/kernel/vmlinux.lds.S）或链接选项可能允许符号重复定义（比如使用了-z muldefs），导致链接器未报错并保留了两个符号实例。另外，若代码中重复使用EXPORT_SYMBOL_GPL(elf_core_dump)导出符号，也可能引发符号表出现重复条目。

• 编译过程不完整导致的符号不一致
  如果编译内核时未完全清理旧目标文件，中途修改代码后仅编译了部分单元，可能导致vmlinux中同时存在新旧版本的elf_core_dump符号。不过这种情况nm和gdb同时显示两个地址的概率较低，可尝试执行make clean && make重新编译内核验证。

内容的提问来源于stack exchange，提问作者prosupcn