爲什麼在編譯libgd時ld崩潰？

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

您確定libm.so是遇到問題時遇到的文件是 ？ libm.so是一個系統庫，它的.SUNW_cap看起來很好（這是我所期望的）。

哦，等一下，試試'LD_OPTIONS = -Dfiles，cap，details'。也許單獨使用'上限' 會告訴您有關處理 功能的最後一個文件的信息。 '文件'會告訴你目前正在處理哪個文件ld（1） 。

而且，一位同事只是提醒我 - 功能部分可以使用Solaris鏈接編輯器創建 ，但如果你把一個重定位目標 與能力，並與GLD重新處理它（或者objcopy把？）你 可能得到一個「無效」功能部分：

% 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）都不應該翻倒。我會得到解決。

Answer 2

嘗試設置「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？