为何C程序DWARF信息中出现同名不同实现的numcompare函数？
numcompare函数条目？ 这两个条目本质是来自不同编译单元的同名函数，核心原因和编译、链接过程中调试信息的生成与合并有关，具体机制如下：
本地static函数的调试条目生成：sort.c里带
ATTRIBUTE_PURE和static修饰的numcompare是文件作用域的函数，编译器在编译sort.c时，会为它生成独立的DWARF调试条目，明确标记它的归属（属于sort.c的编译单元）。static修饰让它的作用域被限制在当前文件，即使外部有同名函数，编译器也会为它生成独立的符号和调试信息。外部库函数的调试信息合并：你发现的第二个条目对应外部库的
strnumcmp内部调用的numcompare——这个numcompare是strnumcmp所在库（比如GNU Coreutils自带的libstrnumcmp库，或者系统依赖的libc）里的函数。如果该库编译时开启了调试信息（默认编译调试版本时会带），那么链接sort可执行文件时，链接器会把依赖库的DWARF调试信息合并到最终的可执行文件中，所以这个来自外部库的numcompare条目就被保留了下来。DWARF的区分机制：DWARF不会因为函数名相同就合并条目，它通过**编译单元（CU）**来区分不同来源的函数。你可以通过查看两个
numcompare条目的DW_AT_compile_unit属性，或者DW_AT_decl_file、DW_AT_decl_line字段，会发现它们分别指向sort.c和strnumcmp所在的源文件（比如strnumcmp.c），属于完全不同的编译单元。
简单来说，就是两个同名函数来自不同的代码文件，各自的调试信息在链接时被合并到了同一个可执行文件的DWARF数据里，所以你会看到两个独立的条目。
内容的提问来源于stack exchange，提问作者Jay
