Hi!,
My customer has "problems with " /usr/ccs/bin/ld" on Solaris 10. This
problem was not experienced prior to upgrading this system to Solaris
10" The stack traces is similar to bug 4967869 which has been integrated
in build s10_55. However, it seems there is not much I can do based on
the information customer provided.
The output of /etc/release is as follows:
Solaris 10 6/06 s10s_u2wos_09a SPARC
Copyright 2006 Sun Microsystems, Inc. All Rights Reserved.
Use is subject to license terms.
Assembled 09 June 2006
Customer has kernel patch 118833-24 (including linker).
bat:/opt/SUNWexplo/output # ld -V
ld: Software Generation Utilities - Solaris Link Editors: 5.10-1.482
Core was generated by `/usr/ccs/bin/ld -Qy -o executable.pure.x /usr/lo'.
Program terminated with signal 11, Segmentation fault.
(gdb) where
#0 0xfea36a10 in sym_enter () from /usr/ccs/bin/../../../lib/libld.so.2
#1 0xfea38b04 in sym_process () from /usr/ccs/bin/../../../lib/libld.so.2
#2 0xfea2a2d4 in process_elf () from /usr/ccs/bin/../../../lib/libld.so.2
#3 0xfea2a7d8 in process_ifl () from /usr/ccs/bin/../../../lib/libld.so.2
#4 0xfea2a9a8 in process_open () from /usr/ccs/bin/../../../lib/libld.so.2
#5 0xfea437a4 in process_files_com () from
/usr/ccs/bin/../../../lib/libld.so.2
#6 0xfea438a4 in process_files () from /usr/ccs/bin/../../../lib/libld.so.2
#7 0xfea45448 in ld_main () from /usr/ccs/bin/../../../lib/libld.so.2
#8 0x00011220 in main ()
(gdb) x/10i 0xfea36a10
0xfea36a10 <sym_enter+852>: lduh [ %i5 + 4 ], %l0
0xfea36a14 <sym_enter+856>: btst 0x10, %l0
0xfea36a18 <sym_enter+860>: bne 0xfea36a34 <sym_enter+888>
0xfea36a1c <sym_enter+864>: nop
0xfea36a20 <sym_enter+868>: ld [ %l1 + 0x2c ], %o3
0xfea36a24 <sym_enter+872>: or %o3, 0x20, %o2
0xfea36a28 <sym_enter+876>: st %o2, [ %l1 + 0x2c ]
0xfea36a2c <sym_enter+880>: ld [ %i3 ], %o1
0xfea36a30 <sym_enter+884>: st %o1, [ %l4 + 0x18 ]
0xfea36a34 <sym_enter+888>: lduh [ %i3 + 0x62 ], %o4
(gdb) info registers
g0 0x0 0
g1 0x8a 138
g2 0x0 0
g3 0x0 0
g4 0x6c 108
g5 0x0 0
g6 0x0 0
g7 0xfeba2000 -21356544
o0 0x18006 98310
o1 0xe112ce2c -518861268
o2 0x0 0
o3 0x2000000 33554432
o4 0x4000000 67108864
o5 0x0 0
sp 0xffbf9268 0xffbf9268
o7 0xb 11
l0 0x0 0
l1 0xed523fa4 -313376860
l2 0xe0c33068 -524079000
l3 0xfea64000 -22659072
l4 0xed523fd8 -313376808
l5 0x8002 32770
l6 0x20008 131080
l7 0x0 0
i0 0x60018 393240
i1 0xed51e3d8 -313400360
i2 0xed523fe0 -313376800
i3 0xed51d5a0 -313404000
i4 0xfea65f78 -22651016
i5 0xed57e3f0 -313007120
fp 0xffbf92d0 0xffbf92d0
i7 0xfea38afc -22836484
y 0x0 0
psr 0xfe000003 -33554429
wim 0x0 0
tbr 0x0 0
pc 0xfea36a10 0xfea36a10 <sym_enter+852>
npc 0xfea36a14 0xfea36a14 <sym_enter+856>
fsr 0x0 0
csr 0x0 0
The libraries are mostly proprietary libraries that have been
instrumented by purify before. It may well be that these libraries
contain incorrect symbol information which caused sun's ld to crash,
however the gnu binutils ld is perfectly happy with them and produces
perfect executables.
Customer cannot provide us with objects or core files since there is too
much proprietary information encoded in them. Customer hopes the stack
trace together with the ld patch level would give us a good hint to
where the problem actually lies.
Any information is appreciated.
Thanks,
Yu-Jing
***************************************************
Yu-Jing Chen
Technical Support Engineer
Remote Services Delivery Software
Phone: 1 800 usa 4 sun option 2 - case number
Working Schedule:
Tuesday through Friday (11:00 AM - 9:00 PM PST)
***************************************************
