Linker 为什么ld在libgd大楼里崩溃？

我尝试在我的

Solaris

10（x86）上构建。在链路阶段，有一个核心转储：

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

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

分析核心转储：

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

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

0xfeedd80c:div%esi
（gdb）我注册esi
esi 0x0 0

---

我能看出原因是除零。但是因为我没有

ld

的源代码，所以无法进行更深入的分析。有人能提供一些关于这个问题的线索吗？提前谢谢

尝试设置“

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)

% 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

---

是否可能sh_entsize值为0？

您确定libm.so是问题出现时正在处理的文件 遇到？libm.so是一个系统库，它是.SUNW_cap 很好（这是我所期望的）

哦，等等，试试'LD_OPTIONS=-d文件、帽子、细节'。也许是“帽子” 孤独是告诉你关于最后一个文件的信息 能力已得到处理。”“文件”将告诉您哪个文件ld（1） 目前正在进行

而且，一位同事刚刚提醒我，可以创建功能部分 使用Solaris链接编辑器，但如果使用可重定位对象 使用gld（或者objcopy？）重新处理它 可能会获得“无效”功能部分：

% 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)

% 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）不应该摔倒。我将得到地址。

执行命令后，输出是

bash-3.2#elfdump-cN.SUNW_cap/usr/lib/libm.so节头[1]：sh_名称：.SUNW_cap sh_地址：0xb4 sh_标志：[SHF_ALLOC]sh_大小：0x10 sh_类型：[SHT_SUNW_cap]sh_偏移：0xb4 sh_entsize:0x8（2个条目）sh_link:0 sh_info:0 sh_addralign:0x4

我们可以从这些信息中学到什么？使用“

LD_OPTIONS=-Dfiles

”后，我找到了根本原因，不是libm，而是另一个库。谢谢顺便说一句，它应该是“

LD\u OPTIONS=-Ddetail

”，而不是

details

。请使用“

ld-Dhelp

”检查。