我正在尝试系统地调试以下问题:
% gcc -fPIC -flto -o try1.o -c try1.c
% gcc -fPIC -flto -o try2.o -c try2.c
% gcc -shared -flto -fPIC -o try.so try1.o try2.o
try2.c:1:14: warning: type of 'aaaaaaaa' does not match original declaration [enabled by default]
try1.c:1:5: note: previously declared here
我这个综合测试,我确切地知道问题是什么 – aaaaaaaa在这里被定义为int,但是那里很短.在我真正的问题中,链接组合了许多对象,这些对象是复杂的构建过程的结果,我不知道哪两个对象包含冲突的定义.
我想通过检查每个链接的目标文件来解决它,看看如何在每个文件中定义符号,并找到一个具有不匹配定义的对.然后我将跟踪构建过程,看看它们是如何构建的并找到根本原因.但我不知道如何看待对象的定义方式.
我尝试了nm -A和objdump -t,但它们没有显示符号类型/大小:
% nm -A try1.o
try1.o:00000001 C __gnu_lto_v1
try1.o:00000000 D aaaaaaaa
% nm -A try2.o
try2.o:00000001 C __gnu_lto_v1
try2.o: U aaaaaaaa
try2.o:00000000 T foo
% objdump -t try1.o | grep aaa
00000000 g O .data 00000004 aaaaaaaa
% objdump -t try2.o | grep aaa
00000000 *UND* 00000000 aaaaaaaa
我的编译器:
% gcc --version
gcc (GCC) 4.8.5 20150623 (Red Hat 4.8.5-4)
Copyright (C) 2015 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
最佳答案 使用nm –print-size. GNU nm默认为BSD格式,仅显示值.这不显示未定义符号的大小,因为链接不需要此信息,也不会存储在任何位置.
使用-flto进行编译时,GCC会添加几个.gnu.lto_.
section,其中包含未定义符号的预期大小.我不知道是否有任何现成的工具可以解析它们.
您可以显示一个hexdump:
F=try2.o; objdump -h $F | grep -o '\.gnu.lto_\S*' | xargs -I% readelf -x % $F