[FIXED] Why the ld crash in building libgd?

Issue

I try to build libgd on my Solaris 10 (x86). In link stage, there is a core dump:

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

I use gdb to analyze the core dump:

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

From gdb, I can see the core occurs at 0xfeedd80c:

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

I can see the cause is dividing zero. But because I don't have the source code of ld, I can't analyse deeper. Could anyone give some clues on this issue? Thanks in advance!

Solution

Are you sure libm.so is the file being processed when the problem is encountered? libm.so is a system library, and it's .SUNW_cap looks fine (which is what I'd expect).

Oh wait, try 'LD_OPTIONS=-Dfiles,cap,details'. Perhaps the 'cap' alone is telling you information in regards the last file where the capabilities were processed. 'file' will tell you which file ld(1) is presently working on.

And, a colleague just reminded me - capabilities sections can be created using the Solaris link-editor, but if you take a relocatable object with capabilities and reprocess it with gld (or perhaps objcopy?) you might get an "invalid" capabilities section:

% 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

Regardless, ld(1) shouldn't be falling over. I'll get that addressed.

Answered By - Rod

Answer Checked By - Dawn Plyler (PHPFixing Volunteer)