This is the mail archive of the
binutils@sourceware.org
mailing list for the binutils project.
Re: Strange ld.gold segmentation error issues.
- From: "ISHIKAWA,chiaki" <ishikawa at yk dot rim dot or dot jp>
- To: binutils at sourceware dot org
- Date: Sun, 01 Jun 2014 01:58:46 +0900
- Subject: Re: Strange ld.gold segmentation error issues.
- Authentication-results: sourceware.org; auth=none
- References: <537A2682 dot 40706 at yk dot rim dot or dot jp>
[stack dump of segmentation error is attached in the comment below.]
(2014/05/20 0:42), ISHIKAWA,chiaki wrote:
> Hi list,
>
> I have seen a few segmentation error from ld.gold in the last few
> weeks during linking of mozilla thunderbird mail client.
> This did not happen in about 12 months after I began using ld.gold for
> linking since last year.
>
> My system:
> Linux vm-debian-amd64 3.12-1-amd64 #1 SMP Debian 3.12.9-1 (2014-02-01)
> x86_64 GNU/Linux
>
> Debian GNU/Linux 64-bit: I am using testing repository as well as
> main repository.
>
> /usr/bin/ld.gold has been upgraded lately in the last couple of months.
>
> /usr/bin/ld.gold --version
> GNU gold (GNU Binutils for Debian 2.24.51.20140425) 1.11
> Copyright (C) 2014 Free Software Foundation, Inc.
> This program is free software; you may redistribute it under the terms of
> the GNU General Public License version 3 or (at your option) a later
> version.
> This program has absolutely no warranty.
>
> I think the cause of the segmentation error may be related to Debian's
> binutils 2.24.51.20140425 which has been installed lately. (It seems
> to based on the git snapshot of binutils with a few tweaks for
> multi-architecture support under Debian. Nothing stood out that may
> affect x86-64 linking when I looked at it, but I could be wrong.)
>
> Here is the information about segfaults from the few observed
> errors. recorded by linux kernel.
> ========================================
>
> messages:May 12 22:40:38 vm-debian-amd64 kernel: [121787.862407]
> ld.gold[16371]: segfault at 2b2df5ec1000 ip 00000000004505c0 sp
> 00007fff2bc98ca0 error 4 in ld.gold[400000+25e000]
> messages:May 13 01:22:29 vm-debian-amd64 kernel: [131503.909365]
> ld.gold[8245]: segfault at 2b19e40d9000 ip 00000000004505c0 sp
> 00007fffa53dcc70 error 4 in ld.gold[400000+25e000]
> messages:May 17 06:31:38 vm-debian-amd64 kernel: [488306.624773]
> ld.gold[10382]: segfault at 2b2a7d625000 ip 00000000004505c0 sp
> 00007fff33a80d70 error 4 in ld.gold[400000+25e000]
> root@vm-debian-amd64:/var/log#
>
> Unfortunately, /usr/bin/ld.gold installed by Debian packaging system
> is stripped and so I cannot correlate ip 00000000004505c0 to a
> function symbol.
>
> So I installed a binary compiled from debian package source file to
> figure out where the error occurs.
>
> ls -ltr /usr/bin/ld*
> -rwxr-xr-x 1 root root 2506064 Apr 28 07:11 /usr/bin/ld.gold*
> -rwxr-xr-x 1 root root 1047648 Apr 28 07:11 /usr/bin/ld.bfd*
> lrwxrwxrwx 1 root root 6 Apr 28 07:11 /usr/bin/ld -> ld.bfd*
> -rwxr-xr-x 1 root root 5280 Apr 28 13:01 /usr/bin/ldd*
> -rwxr-xr-x 1 root root 68814160 May 18 06:10 /usr/bin/ld-new*
> -rwxr-xr-x 1 root root 68814104 May 19 21:15 /usr/bin/ld.new* <-- This!
> ishikawa@vm-debian-amd64:/tmp$
>
> ld.new above is my own version of ld.gold compiled from
> source with debug symbols.
> I invoked it from my ~/bin/ld script.
>
> After the installation of non-stripped ld.new, and re-compiling
> everything for mozilla TB, now I got another segmentation error.
>
> Under /var/log:
> grep segfault messages
> May 19 21:20:47 vm-debian-amd64 kernel: [714565.973445] ld.new[26462]:
> segfault at 2b929377c000 ip 0000000000517240 sp 00007fff8162c0d0 error 4
> in ld.new[400000+358000]
> root@vm-debian-amd64:/var/log#
>
>>From the nm ld.new | sort -n -k 1 :
> 0000000000516980 T _ZN4gold9Gdb_indexD2Ev
> 0000000000517220 T _ZN4gold9Gdb_index10add_symbolEiPKch
> 0000000000517620 T
> _ZN4gold21Gdb_index_info_reader26read_pubnames_and_pubtypesEPNS_9Dwarf_dieE
>
>>From the excerpt of "nm ld.new | sort -n -k 1 | c++filt"
> 0000000000516940 T gold::Gdb_index::print_stats()
> 0000000000516980 T gold::Gdb_index::~Gdb_index()
> 0000000000516980 T gold::Gdb_index::~Gdb_index()
> 0000000000517220 T gold::Gdb_index::add_symbol(int, char const*,
> unsigned char)
> 0000000000517620 T
> gold::Gdb_index_info_reader::read_pubnames_and_pubtypes(gold::Dwarf_die*)
>
> So I think the error (segfault) happened in
> gold::Gdb_index::add_symbol(int, char const*, unsigned char).
>
> But the funny thing is that the created libmozalloc.so seems to be
> usable by another invocation of build (by top-level make) if I invoke
> it again. It did not seem to be necessary to re-create it!
> Very strange.
> Also, the running of build again after I deleted libmozalloc.so runs
> successfully without segmentation error (!).
> So it is history sensitive?!
>
> So maybe it could be related to OOM condition (or may be not.).
>
> The error log from mozilla thunderbird build when the above
> segmentation fault occurred.
>
> [...]
>
> mozalloc.o <--- these are the compilation target.
> mozalloc_abort.o
> mozalloc_oom.o
> /REF-COMM-CENTRAL/comm-central/mozilla/memory/mozalloc/VolatileBufferFallback.cpp:
> In member function ‘bool mozilla::VolatileBuffer::Init(size_t, size_t)’:
> /REF-COMM-CENTRAL/comm-central/mozilla/memory/mozalloc/VolatileBufferFallback.cpp:33:53:
> warning: ignoring return value of ‘int moz_posix_memalign(void**,
> size_t, size_t)’, declared with attribute warn_unused_result
> [-Wunused-result]
> (void)moz_posix_memalign(&mBuf, aAlignment, aSize);
> ^
> libmozalloc.so <==== this is the target that caused ld
> segmentation error.: command arguments
> are listed later.
> Segmentation fault
> collect2: error: ld returned 139 exit status
> /REF-COMM-CENTRAL/comm-central/mozilla/nsprpub/config/rules.mk:298:
> recipe for target 'libnspr4.so' failed
>
> That error was triggered by my non-stripped ld.new.
> It is referred to incorrectly ld.gold in comment
> in my ~/bin/ld script, quoted below, and it was run with the following
> arguments when segmentation error occurred.
>
> ---- ~/bin/ld
> :
> #
> logger "my version of non-stripped ld.gold called with: $*"
> : /usr/bin/ld.gold $*
> /usr/bin/ld.new $*
> --------
>
> May 19 21:20:47 vm-debian-amd64 ishikawa: my version of non-stripped
> ld.gold called with: --sysroot=/ --build-id --eh-frame-hdr -m elf_x86_64
> --hash-style=gnu -shared -o libnspr4.so
> /usr/lib/gcc/x86_64-linux-gnu/4.8/../../../x86_64-linux-gnu/crti.o
> /usr/lib/gcc/x86_64-linux-gnu/4.8/crtbeginS.o
> -L/usr/lib/gcc/x86_64-linux-gnu/4.8
> -L/usr/lib/gcc/x86_64-linux-gnu/4.8/../../../x86_64-linux-gnu
> -L/usr/lib/gcc/x86_64-linux-gnu/4.8/../../../../lib
> -L/lib/x86_64-linux-gnu -L/lib/../lib -L/usr/lib/x86_64-linux-gnu
> -L/usr/lib/../lib -L/usr/lib/gcc/x86_64-linux-gnu/4.8/../../..
> --gdb-index -soname libnspr4.so ./prvrsion.o io/./prfdcach.o
> io/./prmwait.o io/./prmapopt.o io/./priometh.o io/./pripv6.o
> io/./prlayer.o io/./prlog.o io/./prmmap.o io/./prpolevt.o io/./prprf.o
> io/./prscanf.o io/./prstdio.o threads/./prcmon.o threads/./prrwlock.o
> threads/./prtpd.o linking/./prlink.o malloc/./prmalloc.o
> malloc/./prmem.o md/./prosdep.o memory/./prshm.o memory/./prshma.o
> memory/./prseg.o misc/./pralarm.o misc/./pratom.o misc/./prcountr.o
> misc/./prdtoa.o misc/./prenv.o misc/./prerr.o misc/./prerror.o
> misc/./prerrortable.o misc/./prinit.o misc/./prinrval.o misc/./pripc.o
> misc/./prlog2.o misc/./prlong.o misc/./prnetdb.o misc/./praton.o
> misc/./prolock.o misc/./prrng.o misc/./prsystem.o misc/./prthinfo.o
> misc/./prtpool.o misc/./prtrace.o misc/./prtime.o pthreads/./ptsynch.o
> pthreads/./ptio.o pthreads/./ptthread.o pthreads/./ptmisc.o
> md/unix/./unix.o md/unix/./unix_errors.o md/unix/./uxproces.o
> md/unix/./uxrng.o md/unix/./uxshm.o md/unix/./uxwrap.o md/unix/./linux.o
> md/unix/./os_Linux_x86_64.o -z text --build-id -lpthread -ldl -lrt -lgcc
> --as-needed -lgcc_s --no-as-needed -lc -lgcc --as-needed -lgcc_s
> --no-as-needed /usr/lib/gcc/x86_64-linux-gnu/4.8/crtendS.o
> /usr/lib/gcc/x86_64-linux-gnu/4.8/../../../x86_64-linux-gnu/crtn.o
> May 19 21:20:47 vm-debian-amd64 kernel: [714565.973445] ld.new[26462]:
> segfault at 2b929377c000 ip 0000000000517240 sp 00007fff8162c0d0 error 4
> in ld.new[400000+358000]
> root@vm-debian-amd64:/var/log# exit
>
> Any ideas to where to look?
>
> Yes, the compilation runs of Mozilla thunderbird invokes make with
> "-j4" or something and so there are processes running in parallel.
>
> I have 9 GiB of memory. (I am running this linux image in vmplayer and
> so the amount of memory can be tweaked.)
>>From dmesg:
> [ 0.000000] Memory: 9002568K/9215480K available (4723K kernel code,
> 679K rwdata, 1596K rodata, 972K init, 944K bss, 212912K reserved)
>
> I have enough swap space, and so running out of VM space is hard to
> believe though it can not be ruled out. However, I have been compiling
> mozilla Thundrbird for the last 12 months or so with ld.gold until the
> upgrade of binutils versions in the last couple of months.
>
> My compiler is gcc-4.8 (fixed although Debian seems
> to offer 4.9 now.)
>
> I have looked at binutils mail archive and all I could vaguely
> associate with my segmentation error in the last couple of months
> postings was got_index being handled as unsigned int which was
> incorrect. Not sure if that could be related to this intermittent
> error.
>
> That error could not be reproduced by running of make after the target
> libmozalloc.so, which caused the segmentation error, was removed is hard
> to understand :-(
>
> TIA
>
[Stack dump at the time of segfault is included.]
I reported a strange problem of segfault during the linking
of mozilla thunderbird mail client using GNU gold starting this past
month.
Before it was OK.
(This happened after Debian GNU/Linux began shipping
latest binutils based on binutils_2.24.51.20140425. I am not sure
if Debian's version makes sense in binutils mailing list, but it is based on
a snapshot of April, I think.
The ChangeLog of the source used by Debian contains the following
entry at the top.
>2014-04-04 Eric Botcazou <ebotcazou@adacore.com>
>
> PR bootstrap/60620
> * Makefile.def (dependencies): Make gnattools depend on libstdc++-v3.
> * Makefile.in: Regenerate.
ENVIRONMENT:
System
uname -a:
Linux vm-debian-amd64 3.12-1-amd64 #1 SMP Debian 3.12.9-1 (2014-02-01)
x86_64 GNU/Linux
I have used gcc-4.8 (g++-4.8) to compile the binary.
gcc-4.8 --version
gcc-4.8 (Debian 4.8.2-21) 4.8.2
Copyright (C) 2013 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
g++-4.8 --version
g++-4.8 (Debian 4.8.2-21) 4.8.2
Copyright (C) 2013 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
I think g++-4.8 has been working rather fine, and only the switch to
the latest binutils caused this strange issue (I think.).
Oh, I am using -gsplit-dwarf switch to gcc, g++, and
pass -gdb-index to gold. Does it matter? (with the older version of
GNU gold, it did not cause this segmentation error.)
Initially, I suspected that it could be an OOM issue since there are
many processes running "make -j4 ...", but then I found I have more
than 2.5 GB of main memory is free at the time the GNU gold binary was
invoked to produce a .so library just before the segfault occurs The
library is NOT THAT big.
Also, to my surprise, changing "-j4" make switch to "-j3" did not
change the issue. Even with less number of processes invoked by make,
the segfault still occurred. So OOM is unlikely, and come to think of
it, if OOM had happened, the kernel should have recorded it, but I did
not see such messages in kernel logs.
Anyway, so, I modified my local version of "ld" to invoke a shell
script, which
checks if the particular library (here libnspr4.so) is going to be
created, and if so, invokes ld.new (gold binary) under gdb and see
what happens. Otherwise it simply invokes gold binary with the passed
arguments.
(In the previous posting, I thought it was libmozalloc.so that caused
the blowup, but as it turned out it is the next target, libnspr4.so)
Funny, the first few times, it did not trip ?!??
Maybe I was doing something wrong.
On the third try, I could capture the stacktrace.
I wonder if people in the know can deduce something here.
[I obtained three dumps.
One with my stock ~/.gdbinit tailored to mozilla thunderbird
debugging. But it contained a set of spurious warnings related to
files referenced in .gdbinit.
The 2nd ONE was obtained after this .gdbinit file renamed to .gdbinit.save
to remove the spurious warning.
The 3rd one was obtained after I cleared ccache completely.
I cleared ccache's cache to make sure
that I am not using corrupt object files (for some mysterious
reason). I use a version of ccache enhanced to support -gsplit-dwarf.
https://bitbucket.org/zephyrus00jp/ccache-gsplit-dwarf-support
https://bugzilla.samba.org/show_bug.cgi?id=10005
The second and third stack trace matched completely (except for the
process ID that is printed at the end.) So I am sure ccache is not
involved with the problem.
So I am showing the 3rd dump below.
Funny thing is that I can re-invoke top-most make -f client.mk with
suitable environment variable setting, etc., and can create a working
mozilla thunderbird (!?) I wonder in what condition the left over
libnspr4.so is. Maybe the link/build system of mozilla thunderbird is
clever enough to figure out that libnspr4.a is used instead(?), but I
digress.
TIA
--- excerpt from the log ---
Tripping -o libnspr4.so|-o libmozalloc.so
for debugging linking problem
my version of non-stripped ld.gold called with:
PWD=/REF-OBJ-DIR/objdir-tb3/mozilla/nsprpub/pr/src --sysroot=/
--build-id --eh-frame-hdr -m elf_x86_64 --hash-style=gnu -shared -o
libnspr4.so
/usr/lib/gcc/x86_64-linux-gnu/4.8/../../../x86_64-linux-gnu/crti.o
/usr/lib/gcc/x86_64-linux-gnu/4.8/crtbeginS.o
-L/usr/lib/gcc/x86_64-linux-gnu/4.8
-L/usr/lib/gcc/x86_64-linux-gnu/4.8/../../../x86_64-linux-gnu
-L/usr/lib/gcc/x86_64-linux-gnu/4.8/../../../../lib
-L/lib/x86_64-linux-gnu -L/lib/../lib -L/usr/lib/x86_64-linux-gnu
-L/usr/lib/../lib -L/usr/lib/gcc/x86_64-linux-gnu/4.8/../../..
--gdb-index -soname libnspr4.so ./prvrsion.o io/./prfdcach.o
io/./prmwait.o io/./prmapopt.o io/./priometh.o io/./pripv6.o
io/./prlayer.o io/./prlog.o io/./prmmap.o io/./prpolevt.o io/./prprf.o
io/./prscanf.o io/./prstdio.o threads/./prcmon.o threads/./prrwlock.o
threads/./prtpd.o linking/./prlink.o malloc/./prmalloc.o
malloc/./prmem.o md/./prosdep.o memory/./prshm.o memory/./prshma.o
memory/./prseg.o misc/./pralarm.o misc/./pratom.o misc/./prcountr.o
misc/./prdtoa.o misc/./prenv.o misc/./prerr.o misc/./prerror.o
misc/./prerrortable.o misc/./prinit.o misc/./prinrval.o misc/./pripc.o
misc/./prlog2.o misc/./prlong.o misc/./prnetdb.o misc/./praton.o
misc/./prolock.o misc/./prrng.o misc/./prsystem.o misc/./prthinfo.o
misc/./prtpool.o misc/./prtrace.o misc/./prtime.o pthreads/./ptsynch.o
pthreads/./ptio.o pthreads/./ptthread.o pthreads/./ptmisc.o
md/unix/./unix.o md/unix/./unix_errors.o md/unix/./uxproces.o
md/unix/./uxrng.o md/unix/./uxshm.o md/unix/./uxwrap.o md/unix/./linux.o
md/unix/./os_Linux_x86_64.o -z text --build-id -lpthread -ldl -lrt -lgcc
--as-needed -lgcc_s --no-as-needed -lc -lgcc --as-needed -lgcc_s
--no-as-needed /usr/lib/gcc/x86_64-linux-gnu/4.8/crtendS.o
/usr/lib/gcc/x86_64-linux-gnu/4.8/../../../x86_64-linux-gnu/crtn.o
[CI comment: At the time of invocation: vmstat showed the following output.]
procs -----------memory---------- ---swap-- -----io---- -system--
------cpu-----
r b swpd free buff cache si so bi bo in cs us sy
id wa st
0 1 9008 3059096 498332 4088956 0 0 14 19 21 17 1
0 99 0 0
Now calling ld.new via gdb ...
GNU gdb (GDB) 7.6.1
Copyright (C) 2013 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later
<http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law. Type "show copying"
and "show warranty" for details.
This GDB was configured as "x86_64-unknown-linux-gnu".
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>...
Reading symbols from /usr/bin/ld.new...done.
(gdb) Starting program: /usr/bin/ld.new --sysroot=/ --build-id
--eh-frame-hdr -m elf_x86_64 --hash-style=gnu -shared -o libnspr4.so
/usr/lib/gcc/x86_64-linux-gnu/4.8/../../../x86_64-linux-gnu/crti.o
/usr/lib/gcc/x86_64-linux-gnu/4.8/crtbeginS.o
-L/usr/lib/gcc/x86_64-linux-gnu/4.8
-L/usr/lib/gcc/x86_64-linux-gnu/4.8/../../../x86_64-linux-gnu
-L/usr/lib/gcc/x86_64-linux-gnu/4.8/../../../../lib
-L/lib/x86_64-linux-gnu -L/lib/../lib -L/usr/lib/x86_64-linux-gnu
-L/usr/lib/../lib -L/usr/lib/gcc/x86_64-linux-gnu/4.8/../../..
--gdb-index -soname libnspr4.so ./prvrsion.o io/./prfdcach.o
io/./prmwait.o io/./prmapopt.o io/./priometh.o io/./pripv6.o
io/./prlayer.o io/./prlog.o io/./prmmap.o io/./prpolevt.o io/./prprf.o
io/./prscanf.o io/./prstdio.o threads/./prcmon.o threads/./prrwlock.o
threads/./prtpd.o linking/./prlink.o malloc/./prmalloc.o
malloc/./prmem.o md/./prosdep.o memory/./prshm.o memory/./prshma.o
memory/./prseg.o misc/./pralarm.o misc/./pratom.o misc/./prcountr.o
misc/./prdtoa.o misc/./prenv.o misc/./prerr.o misc/./prerror.o
misc/./prerrortable.o misc/./prinit.o misc/./prinrval.o misc/./pripc.o
misc/./prlog2.o misc/./prlong.o misc/./prnetdb.o misc/./praton.o
misc/./prolock.o misc/./prrng.o misc/./prsystem.o misc/./prthinfo.o
misc/./prtpool.o misc/./prtrace.o misc/./prtime.o pthreads/./ptsynch.o
pthreads/./ptio.o pthreads/./ptthread.o pthreads/./ptmisc.o
md/unix/./unix.o md/unix/./unix_errors.o md/unix/./uxproces.o
md/unix/./uxrng.o md/unix/./uxshm.o md/unix/./uxwrap.o md/unix/./linux.o
md/unix/./os_Linux_x86_64.o -z text --build-id -lpthread -ldl -lrt -lgcc
--as-needed -lgcc_s --no-as-needed -lc -lgcc --as-needed -lgcc_s
--no-as-needed /usr/lib/gcc/x86_64-linux-gnu/4.8/crtendS.o
/usr/lib/gcc/x86_64-linux-gnu/4.8/../../../x86_64-linux-gnu/crtn.o
Program received signal SIGSEGV, Segmentation fault.
gold::Gdb_index::add_symbol (this=0x901e90, cu_index=3,
sym_name=0x2aaaaaaec000 <Address 0x2aaaaaaec000 out of bounds>,
flags=0 '\000') at gdb-index.cc:1128
1128 reinterpret_cast<const unsigned char*>(sym_name));
(gdb) #0 gold::Gdb_index::add_symbol (this=0x901e90, cu_index=3,
sym_name=0x2aaaaaaec000 <Address 0x2aaaaaaec000 out of bounds>,
flags=0 '\000') at gdb-index.cc:1128
#1 0x0000000000517602 in gold::Gdb_index_info_reader::read_pubtable (
this=0x7fffffff5a30, table=0x9022d0, offset=<optimized out>)
at gdb-index.cc:879
#2 0x00000000005176c9 in
gold::Gdb_index_info_reader::read_pubnames_and_pubtypes
(this=0x7fffffff5a30, die=0x7fffffff5960) at gdb-index.cc:942
#3 0x0000000000518009 in gold::Gdb_index_info_reader::visit_top_die (
this=0x7fffffff5a30, die=0x7fffffff5960) at gdb-index.cc:379
#4 0x00000000005180d3 in
gold::Gdb_index_info_reader::visit_compilation_unit
(this=0x7fffffff5a30, cu_offset=<optimized out>,
cu_length=<optimized out>, root_die=<optimized out>) at gdb-index.cc:326
#5 0x000000000062a8f2 in gold::Dwarf_info_reader::do_parse<false> (
this=this@entry=0x7fffffff5a30) at dwarf_reader.cc:1363
#6 0x000000000062746e in gold::Dwarf_info_reader::parse (
this=this@entry=0x7fffffff5a30) at dwarf_reader.cc:1234
#7 0x00000000005187b1 in gold::Gdb_index::scan_debug_info (this=0x901e90,
is_type_unit=is_type_unit@entry=false, object=object@entry=0x946f90,
symbols=0x2aaaaaaeb150 "", symbols@entry=0xb <Address 0xb out of
bounds>,
symbols_size=symbols_size@entry=504, shndx=<optimized out>,
reloc_shndx=9, reloc_type=4) at gdb-index.cc:1119
#8 0x0000000000550939 in gold::Layout::add_to_gdb_index<64, false> (
this=this@entry=0x7fffffff6f30, is_type_unit=is_type_unit@entry=false,
object=object@entry=0x946f90, symbols=0xb <Address 0xb out of bounds>,
symbols@entry=0x2aaaaaaeb150 "", symbols_size=symbols_size@entry=504,
shndx=<optimized out>, reloc_shndx=9, reloc_type=4) at layout.cc:1569
#9 0x0000000000576fe6 in gold::Sized_relobj_file<64, false>::do_layout (
this=0x946f90, symtab=0x7fffffff6cd0, layout=0x7fffffff6f30,
sd=0x947190)
at object.cc:1790
#10 0x00000000005d1e90 in layout (sd=<optimized out>, layout=
{void (gold::Read_symbols_data *, gold::Layout *, gold::Symbol_table
*, gold::Object * const)} 0x5d1e82
<gold::Add_symbols::run(gold::Workqueue*)+210>,
symtab=<optimized out>, this=<optimized out>) at object.h:576
#11 gold::Add_symbols::run (this=0x94a560) at readsyms.cc:634
#12 0x000000000061c635 in gold::Workqueue::find_and_run_task (
this=this@entry=0x7fffffff6980, thread_number=thread_number@entry=0)
at workqueue.cc:319
#13 0x000000000061c95a in gold::Workqueue::process (
this=this@entry=0x7fffffff6980, thread_number=thread_number@entry=0)
at workqueue.cc:495
#14 0x00000000004068cc in main (argc=97, argv=0x7fffffffced8) at main.cc:252
(gdb) #1 0x0000000000517602 in gold::Gdb_index_info_reader::read_pubtable (
this=0x7fffffff5a30, table=0x9022d0, offset=<optimized out>)
at gdb-index.cc:879
879 this->gdb_index_->add_symbol(this->cu_index_, name, flag_byte);
(gdb) #2 0x00000000005176c9 in
gold::Gdb_index_info_reader::read_pubnames_and_pubtypes
(this=0x7fffffff5a30, die=0x7fffffff5960) at gdb-index.cc:942
942 names = this->read_pubtable(this->gdb_index_->pubnames_table(),
offset);
(gdb) A debugging session is active.
Inferior 1 [process 10815] will be killed.
Quit anyway? (y or n) [answered Y; input not from terminal]
warning: the debug information found in "/lib64/ld-2.18.so" does not
match "/lib64/ld-linux-x86-64.so.2" (CRC mismatch).
warning: Could not load shared library symbols for linux-vdso.so.1.
Do you need "set solib-search-path" or "set sysroot"?
========================================
Thank you again for offering a great linker.
It has sped up link time and reduced memory consumption very much.