Question

我尝试在Solaris 10（x86）上构建libgd。在链接阶段，有一个核心转储：

libtool: link: gcc -std=gnu99 -shared -Wl,-z -Wl,text -Wl,-h -Wl,libgd.so.3 -o .libs/libgd.so.3.0.0  .libs/gd.o .libs/gd_color.o .libs/gd_color_map.o .libs/gd_transform.o .libs/gdfx.o .libs/gd_security.o .libs/gd_gd.o .libs/gd_gd2.o .libs/gd_io.o .libs/gd_io_dp.o .libs/gd_gif_in.o .libs/gd_gif_out.o .libs/gd_io_file.o .libs/gd_io_ss.o .libs/gd_jpeg.o .libs/gd_png.o .libs/gd_ss.o .libs/gd_topal.o .libs/gd_wbmp.o .libs/gdcache.o .libs/gdfontg.o .libs/gdfontl.o .libs/gdfontmb.o .libs/gdfonts.o .libs/gdfontt.o .libs/gdft.o .libs/gdhelpers.o .libs/gdkanji.o .libs/gdtables.o .libs/gdxpm.o .libs/wbmp.o .libs/gd_filter.o .libs/gd_nnquant.o .libs/gd_rotate.o .libs/gd_matrix.o .libs/gd_interpolation.o .libs/gd_crop.o .libs/webpimg.o .libs/gd_webp.o .libs/gd_tiff.o .libs/gd_tga.o .libs/gd_bmp.o .libs/gd_xbm.o .libs/gd_color_match.o   -R/usr/local/lib -R/usr/local/lib -R/usr/sfw/lib -R/usr/local/ssl/lib -R/usr/openwin/lib -R/usr/lib -R/usr/X11R6/lib -R/usr/local/BerkeleyDB.4.7/lib -R/usr/local/BerkeleyDB.4.2/lib -L/usr/openwin/lib -L/usr/local/lib /usr/local/lib/libiconv.so -lz -lm /usr/local/lib/libpng12.so -L/usr/local/ssl/lib -L/usr/lib -L/usr/X11R6/lib -L/usr/local/BerkeleyDB.4.7/lib -L/usr/sfw/lib /usr/local/lib/libfreetype.so /usr/local/lib/libfontconfig.so -L/usr/local/BerkeleyDB.4.2/lib -lc
collect2: ld terminated with signal 8 [Arithmetic Exception], core dumped
make[2]: *** [libgd.la] Error 1
make[2]: Leaving directory `/data1/nan/libgd-2.1.0/src'
make[1]: *** [all] Error 2
make[1]: Leaving directory `/data1/nan/libgd-2.1.0/src'
make: *** [all-recursive] Error 1

我使用gdb来分析核心转储：

Core was generated by `/usr/ccs/bin/ld -G -dy -z text -R/usr/local/lib -R/usr/local/lib -R/usr/sfw/lib'.
Program terminated with signal 8, Arithmetic exception.
[New process 92717    ]
#0  0xfeedd80c in process_cap () from /lib/libld.so.4
(gdb) bt
#0  0xfeedd80c in process_cap () from /lib/libld.so.4
#1  0xfeee002a in process_elf () from /lib/libld.so.4
#2  0xfeee0663 in ld32_process_ifl () from /lib/libld.so.4
#3  0xfeee0aa8 in ld32_process_open () from /lib/libld.so.4
#4  0xfeed9557 in process_files_com () from /lib/libld.so.4
#5  0xfeed96a4 in ld32_process_files () from /lib/libld.so.4
#6  0xfeedb58b in ld32_main () from /lib/libld.so.4
#7  0x08051a82 in main ()

从gdb，我可以看到核心发生在0xfeedd80c：

0xfeedd80c <process_cap+64>:    div    %esi
(gdb) i registers esi
esi            0x0      0

我可以看到原因是零。但是因为我没有ld的源代码，所以我无法深入分析。有人能就这个问题提供一些线索吗？提前谢谢！

Answer 1

尝试设置“LD_OPTIONS=-Dcap,details”并执行链接阶段。

这应该标识导致问题的功能的文件。使用“elfdump -H”检查此输入文件。

如果您可以确定可疑输入文件，请查看功能部分：

% elfdump -cN.SUNW_cap foo.o

Section Header[1]:  sh_name: .SUNW_cap
    sh_addr:      0xf4            sh_flags:   [ SHF_ALLOC SHF_INFO_LINK ]
    sh_size:      0xf8            sh_type:    [ SHT_SUNW_cap ]
    sh_offset:    0xf4            sh_entsize: 0x8 (31 entries)

sh_entsize值是否可能为0？

Answer 2

你确定libm.so是问题出来时正在处理的文件吗？遇到过吗？ libm.so是一个系统库，它的.SUNW_cap看起来像很好（这是我所期待的）。

哦等等，试试LD_OPTIONS = -Dfiles，cap，details＆＃39;。也许＆＃39; cap＆＃39; 单独告诉你关于最后一个文件的信息能力得到了处理。＆＃39;文件＆＃39;会告诉你哪个档案ld（1）目前正在努力。

并且，一位同事刚刚提醒我 - 可以创建功能部分使用Solaris链接编辑器，但是如果您使用可重定位目标文件有能力并用gld（或者objcopy？）重新处理它可能会得到一个＆＃34;无效＆＃34;能力部分：

% elfdump -H foo.o
...
Object Capabilities:
    index  tag           value
      [0]  CA_SUNW_HW_1  0x800  [ SSE ]

% gld -r foo.o -o bar.o
% elfdump -H bar.o
bar.o: .SUNW_cap: zero sh_entsize information, expected 0x8

无论如何，ld（1）不应该摔倒。我会解决这个问题。

为什么ld在构建libgd时崩溃了？

2 个答案: