Bug 12525 - gold SEGV linking libgcc_s.so.1 on Solaris 11/x86
Summary: gold SEGV linking libgcc_s.so.1 on Solaris 11/x86
Status: RESOLVED FIXED
Alias: None
Product: binutils
Classification: Unclassified
Component: gold (show other bugs)
Version: 2.22
: P2 normal
Target Milestone: ---
Assignee: Ian Lance Taylor
URL:
Keywords:
: 11748 (view as bug list)
Depends on:
Blocks:
 
Reported: 2011-03-01 13:18 UTC by Rainer Orth
Modified: 2011-07-09 00:16 UTC (History)
1 user (show)

See Also:
Host:
Target:
Build:
Last reconfirmed:


Attachments
Possible patch (1.73 KB, patch)
2011-03-08 05:33 UTC, Ian Lance Taylor
Details | Diff
object files for failing two_file_shared_1_nonpic.so test (6.61 KB, application/x-bzip2)
2011-03-14 19:42 UTC, Rainer Orth
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Rainer Orth 2011-03-01 13:18:08 UTC
I've just tried to bootstrap GCC mainline with gold from either binutils 2.21 or
HEAD, with no success: the first time gold is called (to link libgcc_s.so.1), it
first errs parsing the command line and then SEGVs:

$ gold-2.21 --eh-frame-hdr -V -G -dy -z text -m elf_i386 -Y P,/usr/ccs/lib:/usr/lib -Qy -o ./libgcc_s.so.1.tmp /usr/lib/crti.o /usr/lib/values-Xa.o /var/gcc/regression/trunk/11-gcc-gas-gold/build/./gcc/crtbegin.o -L/var/gcc/regression/trunk/11-gcc-gas-gold/build/./gcc -L. --soname=libgcc_s.so.1 --version-script=libgcc.map _muldi3_s.o _negdi2_s.o _lshrdi3_s.o _ashldi3_s.o _ashrdi3_s.o _cmpdi2_s.o _ucmpdi2_s.o _clear_cache_s.o _enable_execute_stack_s.o _trampoline_s.o __main_s.o _absvsi2_s.o _absvdi2_s.o _addvsi3_s.o _addvdi3_s.o _subvsi3_s.o _subvdi3_s.o _mulvsi3_s.o _mulvdi3_s.o _negvsi2_s.o _negvdi2_s.o _ctors_s.o _ffssi2_s.o _ffsdi2_s.o _clz_s.o _clzsi2_s.o _clzdi2_s.o _ctzsi2_s.o _ctzdi2_s.o _popcount_tab_s.o _popcountsi2_s.o _popcountdi2_s.o _paritysi2_s.o _paritydi2_s.o _powisf2_s.o _powidf2_s.o _powixf2_s.o _powitf2_s.o _mulsc3_s.o _muldc3_s.o _mulxc3_s.o _multc3_s.o _divsc3_s.o _divdc3_s.o _divxc3_s.o _divtc3_s.o _bswapsi2_s.o _bswapdi2_s.o _fixunssfsi_s.o _fixunsdfsi_s.o _fixunsxfsi_s.o _fixsfdi_s.o _fixdfdi_s.o _fixxfdi_s.o _fixunssfdi_s.o _fixunsdfdi_s.o _fixunsxfdi_s.o _floatdisf_s.o _floatdidf_s.o _floatdixf_s.o _floatundisf_s.o _floatundidf_s.o _floatundixf_s.o _divdi3_s.o _moddi3_s.o _udivdi3_s.o _umoddi3_s.o _udiv_w_sdiv_s.o _udivmoddi4_s.o addtf3_s.o divtf3_s.o eqtf2_s.o getf2_s.o letf2_s.o multf3_s.o negtf2_s.o subtf3_s.o unordtf2_s.o fixtfsi_s.o fixunstfsi_s.o floatsitf_s.o floatunsitf_s.o fixtfdi_s.o fixunstfdi_s.o floatditf_s.o floatunditf_s.o extendsftf2_s.o extenddftf2_s.o extendxftf2_s.o trunctfsf2_s.o trunctfdf2_s.o trunctfxf2_s.o tf-signs_s.o unwind-dw2_s.o unwind-dw2-fde-glibc_s.o unwind-sjlj_s.o gthr-gnat_s.o unwind-c_s.o emutls_s.o -lc /var/gcc/regression/trunk/11-gcc-gas-gold/build/./gcc/crtend.o /usr/lib/crtn.o
GNU gold (GNU Binutils 2.21) 1.10
  Supported targets:
   elf32-i386
   elf32-i386-freebsd
   elf64-x86-64
   elf64-x86-64-freebsd
   elf64-sparc
   elf32-sparc
   elf64-powerpcle
   elf64-powerpc
   elf32-powerpcle
   elf32-powerpc
   elf32-bigarm
   elf32-littlearm
gold-2.21: error: cannot open text: No such file or directory
Bus Error

The cannot open text is obviously suspicious: -z text involves no file `text'.
The SEGV (if run under gdb) happens here:

Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 1 (LWP 1)]
gold::Symbol_table::sized_write_symbol<32, false> (this=0x8046d28, sym=0x8622798, value=0, shndx=65521, binding=elfcpp::STB_GLOBAL, pool=0x8046b80, p=0xfe52e9b4 <Address 0xfe52e9b4 out of bounds>) at /vol/gnu/src/binutils/binutils-2.21/gold/symtab.cc:2865
(gdb) where
#0  gold::Symbol_table::sized_write_symbol<32, false> (this=0x8046d28, sym=0x8622798, value=0, shndx=65521, binding=elfcpp::STB_GLOBAL, pool=0x8046b80, p=0xfe52e9b4 <Address 0xfe52e9b4 out of bounds>) at /vol/gnu/src/binutils/binutils-2.21/gold/symtab.cc:2865
#1  0x082dc331 in gold::Symbol_table::sized_write_globals<32, false> (this=0x8046d28, sympool=0x8046b80, dynpool=0x8046bc4, symtab_xindex=0x0, dynsym_xindex=0x0, of=0x858a758) at /vol/gnu/src/binutils/binutils-2.21/gold/symtab.cc:2832
#2  0x081fc9e8 in gold::Write_symbols_task::run (this=0x8645418) at /vol/gnu/src/binutils/binutils-2.21/gold/layout.cc:4346
#3  0x082eb52d in gold::Workqueue::find_and_run_task (this=0x804703c, thread_number=0) at /vol/gnu/src/binutils/binutils-2.21/gold/workqueue.cc:319
#4  0x082eb8e4 in gold::Workqueue::process (this=0x804703c, thread_number=0) at /vol/gnu/src/binutils/binutils-2.21/gold/workqueue.cc:495
#5  0x081303a0 in main (argc=123, argv=0x804710c) at /vol/gnu/src/binutils/binutils-2.21/gold/main.cc:247  

(gdb) p sym
$8 = (gold::Sized_symbol<32> *) 0x8622798
(gdb) p *sym
$9 = {<gold::Symbol> = {name_ = 0x8565233 "GCC_4.5.0", version_ = 0x8565233 "GCC_4.5.0", u_ = {from_object = {object = 0x0, shndx = 0}, in_output_data = {output_data = 0x0, offset_is_from_end = false}, in_output_segment = {output_segment = 0x0, offset_base = gold::Symbol::SEGMENT_START}}, symtab_index_ = 395, dynsym_index_ = 153, got_offsets_ = {got_type_ = 4294967295, got_offset_ = 0, got_next_ = 0x0}, plt_offset_ = 4294967295, type_ = elfcpp::STT_OBJECT, binding_ = elfcpp::STB_GLOBAL, visibility_ = elfcpp::STV_DEFAULT, nonvis_ = 0, source_ = gold::Symbol::IS_CONSTANT, is_def_ = true, is_forwarder_ = false, has_alias_ = false, needs_dynsym_entry_ = true, in_reg_ = true, in_dyn_ = false, needs_dynsym_value_ = false, has_warning_ = false, is_copied_from_dynobj_ = false, is_forced_local_ = false, is_ordinary_shndx_ = false, in_real_elf_ = true, is_defined_in_discarded_section_ = false, undef_binding_set_ = false, undef_binding_weak_ = false}, value_ = 0, symsize_ = 0}

Since my command of C++ is practically non-existant, I don't know how to go from
here.

binutils/gold were built with either g++ 4.4.2 and -g -O2 or g++ 4.5.2 and
-g3 -O0, but this makes no difference.
Comment 1 Ian Lance Taylor 2011-03-01 14:29:45 UTC
At least part of the problem is that gold does not support the -dy option.  That is interpreted as the -d option followed by the -y option.  The -y option takes an argument, which is the string "-z".  The string "text" is then taken to name an input file.

That does not explain the crash.  The value of the parameter "p" is apparently incorrect, but I don't see what could cause that to happen.  I'll need to be able to recreate this in the debugger somehow.
Comment 2 Rainer Orth 2011-03-01 14:45:36 UTC
> --- Comment #1 from Ian Lance Taylor <ian at airs dot com> 2011-03-01 14:29:45 UTC ---
> At least part of the problem is that gold does not support the -dy option. 
> That is interpreted as the -d option followed by the -y option.  The -y option
> takes an argument, which is the string "-z".  The string "text" is then taken
> to name an input file.

I see.  gld 2.21 does handle it though, so I suppose gold should as well
to be a drop-in replacement?

> That does not explain the crash.  The value of the parameter "p" is apparently
> incorrect, but I don't see what could cause that to happen.  I'll need to be
> able to recreate this in the debugger somehow.

I've had a look:

(gdb) up
#2  0x085c959d in gold::Symbol_table::sized_write_globals<32, false> (this=0x8046d9c, sympool=0x8046bf4, dynpool=0x8046c38, symtab_xindex=0x0, dynsym_xindex=0x0, of=0x897f3d0) at /vol/gnu/src/binutils/binutils-hg/gold/symtab.cc:2850
(gdb) p ps
$1 = (unsigned char *) 0xfe51e9b4 <Address 0xfe51e9b4 out of bounds>
(gdb) p psyms
$2 = (unsigned char *) 0xfe51e874 <Address 0xfe51e874 out of bounds>

So it seems the bad value is from symtab.cc:2706:

    psyms = of->get_output_view(this->offset_, oview_size);

gold::Output_file::get_output_view (this=0x897f3d0, start=383092, size=2752) at /vol/gnu/src/binutils/binutils-hg/gold/output.h:4105
(gdb) p this->base_
$5 = (unsigned char *) 0xfe4c1000 <Address 0xfe4c1000 out of bounds>
(gdb) p start
$6 = 383092
(gdb) p this->base_ + start
$7 = (unsigned char *) 0xfe51e874 <Address 0xfe51e874 out of bounds>

The bad value for base_ is already in layout.cc
(Write_symbols_task::run), but I cannot readily see how to trace it back
further up.

	Rainer
Comment 3 Ian Lance Taylor 2011-03-02 05:59:33 UTC
Yes, gold should recognize -dy.  That's a bug.
Comment 4 Ian Lance Taylor 2011-03-02 06:03:01 UTC
It is possible that gdb is misleading in saying <Address NNN out of bounds>.  I don't know.  The address should be allocated via the call to mmap in Output_file::map_no_anonymous called indirectly from Output_file::open.
Comment 5 Rainer Orth 2011-03-03 14:54:39 UTC
> --- Comment #3 from Ian Lance Taylor <ian at airs dot com> 2011-03-02 05:59:33 UTC ---
> Yes, gold should recognize -dy.  That's a bug.

Should I file a separate PR for that?

	Rainer
Comment 6 Rainer Orth 2011-03-03 15:19:05 UTC
> --- Comment #4 from Ian Lance Taylor <ian at airs dot com> 2011-03-02 06:03:01 UTC ---
> It is possible that gdb is misleading in saying <Address NNN out of bounds>.  I
> don't know.  The address should be allocated via the call to mmap in

It's not: I've checked the address against the pmap output and that part
of the address space is indeed not mapped.

> Output_file::map_no_anonymous called indirectly from Output_file::open.

I see: I've set a breakpoint there and upon the first call, ::mmap
returns 

(gdb) p base
$20 = (void *) 0xfe4c1000

but

(gdb) p this->base_
$21 = (unsigned char *) 0xfe4c1000 <Address 0xfe4c1000 out of bounds>

and pmap indicates that this address is not mapped.

It turns out that this is called for the output file:

(gdb) p this->o_
$26 = 114

and with pfiles -F, I see

 114: S_IFREG mode:0755 dev:171,65630 ino:1165706 uid:2110 gid:4620 size:0
      O_RDWR|O_CREAT|O_TRUNC|O_LARGEFILE FD_CLOEXEC
      /vol/gcc/obj/regression/trunk/11-gcc-gas-gold/build/i386-pc-solaris2.11/libgcc/libgcc_s.so.1.tmp
      offset:0

Maybe the bug is related to this section in mmap(2):

     The mmap() function allows [pa, pa + len) to  extend  beyond
     the  end  of  the  object both at the time of the mmap() and
     while the mapping persists, such as when the file is created
     prior  to  the  mmap() call and has no contents, or when the
     file is truncated. Any reference to addresses beyond the end
     of  the  object,  however,  will result in the delivery of a
     SIGBUS or SIGSEGV signal. The mmap() function cannot be used
     to implicitly extend the length of files.

	Rainer
Comment 7 Ian Lance Taylor 2011-03-03 16:39:12 UTC
The intention of the code is that the file is guaranteed to be large enough by the call to posix_fallocate in Output_file::map_no_anonymous.  Does Solaris have posix_fallocate?  If it does, does it actually grow the file?

If Solaris does not have posix_fallocate, the configure script should detect that, and cause gold to provide a simple implementation, at the top of output.cc, which calls ftruncate and hopes for the best.  Does Solaris provide ftruncate?  If it does, does it actually grow the file?

If Solaris does not have ftruncate, there are various implementations provided in ftruncate.c.  Which one of those winds up getting used?
Comment 8 Rainer Orth 2011-03-04 14:48:43 UTC
> --- Comment #7 from Ian Lance Taylor <ian at airs dot com> 2011-03-03 16:39:12 UTC ---
> The intention of the code is that the file is guaranteed to be large enough by
> the call to posix_fallocate in Output_file::map_no_anonymous.  Does Solaris
> have posix_fallocate?  If it does, does it actually grow the file?

It does, starting from Solaris 11.  Looking at truss output, I see this:

1813:   fcntl(109, F_ALLOCSP64, 0x08043D30)             Err#22 EINVAL
1813:           typ=F_WRLCK  whence=SEEK_SET start=1686135440932864 len=-75608896336560128 sys=134509716 pid=144176112

which, according to the OpenSolaris sources, is called from
posix_fallocate.  fcntl expects a struct flock64 here, or struct flock
for the F_ALLOCSP case.

What seems to be happening is this: for a largefile environment,
<fcntl.h> has

#pragma redefine_extname        posix_fallocate posix_fallocate64

and

extern int posix_fallocate64(int, off64_t, off64_t);

I can see that gold has a reference to posix_fallocate64, but suspect
that the second and third args are still off_t, not off64_t.

> If Solaris does not have posix_fallocate, the configure script should detect
> that, and cause gold to provide a simple implementation, at the top of
> output.cc, which calls ftruncate and hopes for the best.  Does Solaris provide
> ftruncate?  If it does, does it actually grow the file?

ftruncate() is present at least as far back as Solaris 8.  According to
the man page, it does grow files.

	Rainer
Comment 9 Ian Lance Taylor 2011-03-04 19:08:43 UTC
output.cc does #include <fcntl.h>.  gold is always compiled with -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64.  Those two facts together should ensure that posix_fallocate is called with the right types.  Can you suggest a way that the gold source should be changed to fix this?
Comment 10 Rainer Orth 2011-03-07 19:10:06 UTC
> --- Comment #9 from Ian Lance Taylor <ian at airs dot com> 2011-03-04 19:08:43 UTC ---
> output.cc does #include <fcntl.h>.  gold is always compiled with
> -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64.  Those two facts together should
> ensure that posix_fallocate is called with the right types.  Can you suggest a
> way that the gold source should be changed to fix this?

Not yet, since this was just a guess based on the fact that truss showed
impossibly large values for a couple of the fcntl struct flock64
members.  I'll have to analyse this further.

In the meantime, I've tried to disable posix_fallocate in config.h, thus
using ftruncate (or rather ftruncate64) instead.  This works (which
suggests that my guess above may be wrong), but linking libgcc_s.so.1
fails again like this:

gold-2.21: internal error in get_fde_pc, at /vol/gnu/src/binutils/binutils-2.21/gold/ehframe.cc:281

According to gcc/config/i386/sol2.h (ASM_PREFERRED_EH_DATA_FORMAT),
Solaris 2/x86 uses datarel encoding, which isn't handled yet in
gold/ehframe.cc (Eh_frame_hdr::get_fde_pc).

	Rainer
Comment 11 cvs-commit@gcc.gnu.org 2011-03-07 22:51:43 UTC
CVSROOT:	/cvs/src
Module name:	src
Changes by:	ian@sourceware.org	2011-03-07 22:51:40

Modified files:
	gold           : ChangeLog options.h 

Log message:
	PR gold/12525
	* options.h (class General_options): Add -dy and -dn.

Patches:
http://sourceware.org/cgi-bin/cvsweb.cgi/src/gold/ChangeLog.diff?cvsroot=src&r1=1.700&r2=1.701
http://sourceware.org/cgi-bin/cvsweb.cgi/src/gold/options.h.diff?cvsroot=src&r1=1.154&r2=1.155
Comment 12 cvs-commit@gcc.gnu.org 2011-03-07 22:51:54 UTC
CVSROOT:	/cvs/src
Module name:	src
Branch: 	binutils-2_21-branch
Changes by:	ian@sourceware.org	2011-03-07 22:51:50

Modified files:
	gold           : ChangeLog options.h 

Log message:
	PR gold/12525
	* options.h (class General_options): Add -dy and -dn.

Patches:
http://sourceware.org/cgi-bin/cvsweb.cgi/src/gold/ChangeLog.diff?cvsroot=src&only_with_tag=binutils-2_21-branch&r1=1.664.2.18&r2=1.664.2.19
http://sourceware.org/cgi-bin/cvsweb.cgi/src/gold/options.h.diff?cvsroot=src&only_with_tag=binutils-2_21-branch&r1=1.152&r2=1.152.2.1
Comment 13 Ian Lance Taylor 2011-03-08 05:33:07 UTC
Created attachment 5280 [details]
Possible patch

Please try this patch to see if it fixes the assertion failure on get_fde_pc.  The key will be whether the various exception tests in the testsuite pass.
Comment 14 Rainer Orth 2011-03-08 10:18:43 UTC
"ian at airs dot com" <sourceware-bugzilla@sourceware.org> writes:
> --- Comment #13 from Ian Lance Taylor <ian at airs dot com> 2011-03-08 05:33:07 UTC ---
> Created attachment 5280 [details]
>   --> http://sourceware.org/bugzilla/attachment.cgi?id=5280
> Possible patch
>
> Please try this patch to see if it fixes the assertion failure on get_fde_pc. 
> The key will be whether the various exception tests in the testsuite pass.

That test helped me get further along in the GCC bootstrap, but I'm now
failing to link the 64-bit libgomp.so:

gold-2.21.51: fatal error: .libs/team.o: readv failed: Invalid argument

With truss, I see that readv is called like this:

11626:  readv(21, 0x080438E4, 17)                       Err#22 EINVAL
11626:          iov_base = 0xFE809CA0  iov_len = 2807
11626:          iov_base = 0x080418E4  iov_len = 33
11626:          iov_base = 0xFE80B9A8  iov_len = 41
11626:          iov_base = 0x080418E4  iov_len = 15
11626:          iov_base = 0xFE80A7A0  iov_len = 71
11626:          iov_base = 0x080418E4  iov_len = 1
11626:          iov_base = 0xFE80D8E0  iov_len = 8
11626:          iov_base = 0xFE80A7F0  iov_len = 14
11626:          iov_base = 0x080418E4  iov_len = 2
11626:          iov_base = 0xFE80D8F8  iov_len = 8
11626:          iov_base = 0xFE81A858  iov_len = 4666
11626:          iov_base = 0xFE824120  iov_len = 1059
11626:          iov_base = 0xFE830BE8  iov_len = 5233
11626:          iov_base = 0xFE83B4FE  iov_len = 464
11626:          iov_base = 0xFE8369D6  iov_len = 1156
11626:          iov_base = 0x080418E4  iov_len = 2494

i.e. iovcnt is 17, but iov[] has only 16 members.  Seems inconsistent to
me, though this could be a truss artefact.

	Rainer
Comment 15 Ian Lance Taylor 2011-03-08 14:10:34 UTC
What is the value of IOV_MAX on Solaris?  The man page implies that it is defined in some header file, perhaps <stdio.h> or <limits.h>.
Comment 16 Rainer Orth 2011-03-08 14:14:01 UTC
> --- Comment #15 from Ian Lance Taylor <ian at airs dot com> 2011-03-08 14:10:34 UTC ---
> What is the value of IOV_MAX on Solaris?  The man page implies that it is
> defined in some header file, perhaps <stdio.h> or <limits.h>.

It's 16, from <limits.h>.  That certainly explains the failure.

	Rainer
Comment 17 Ian Lance Taylor 2011-03-08 14:28:19 UTC
Thanks.  I would also be interesting in knowing whether gold can pass its tests with the patch I sent, even before you succeed in getting gcc to build.
Comment 18 Rainer Orth 2011-03-08 14:39:08 UTC
> --- Comment #17 from Ian Lance Taylor <ian at airs dot com> 2011-03-08 14:28:19 UTC ---
> Thanks.  I would also be interesting in knowing whether gold can pass its tests
> with the patch I sent, even before you succeed in getting gcc to build.

Apart from the readv stuff, there are a couple of other errors:

gcctestdir/ld: error: cannot find -lm
gcctestdir/ld: error: cannot find -lc
gcctestdir/ld: /usr/lib/crt1.o: in function _start:fsr.s(.text+0x11): error: undefined reference to 'atexit'
gcctestdir/ld: /usr/lib/crt1.o: in function _start:fsr.s(.text+0x1e): error: undefined reference to 'atexit'
gcctestdir/ld: /usr/lib/crt1.o: in function _start:fsr.s(.text+0x3f): error: undefined reference to 'atexit'
gcctestdir/ld: /usr/lib/crt1.o: in function _start:fsr.s(.text+0x70): error: undefined reference to '__fpstart'
gcctestdir/ld: /usr/lib/crt1.o: in function _start:fsr.s(.text+0x8b): error: undefined reference to 'exit'
gcctestdir/ld: /usr/lib/crt1.o: in function _start:fsr.s(.text+0x97): error: undefined reference to '_exit'
gcctestdir/ld: fatal error: basic_test.o: readv failed: Invalid argument
collect2: ld returned 1 exit status
make[3]: *** [basic_static_test] Error 1

gcctestdir/ld: error: read-only segment has dynamic relocations
collect2: ld returned 1 exit status
make[3]: *** [two_file_shared_1_nonpic.so] Error 1

gcctestdir/ld: internal error in override_version, at /vol/gnu/src/binutils/binutils-hg/gold/resolve.cc:61
collect2: ld returned 1 exit status
make[3]: *** [weak_test] Error 1

gcctestdir/ld: fatal error: ver_matching_def_pic.o: readv failed: Invalid argument
collect2: ld returned 1 exit status
make[3]: *** [ver_matching_def.so] Error 1

	Rainer
Comment 19 cvs-commit@gcc.gnu.org 2011-03-09 01:50:37 UTC
CVSROOT:	/cvs/src
Module name:	src
Changes by:	ian@sourceware.org	2011-03-09 01:50:33

Modified files:
	gold           : ChangeLog fileread.h fileread.cc 

Log message:
	PR gold/12525
	* fileread.cc: #include <climits>.
	(GOLD_IOV_MAX): Define.
	(File_read::read_multiple): Limit number of entries by iov_max.
	* fileread.h (class File_read): Always set max_readv_entries to
	128.

Patches:
http://sourceware.org/cgi-bin/cvsweb.cgi/src/gold/ChangeLog.diff?cvsroot=src&r1=1.701&r2=1.702
http://sourceware.org/cgi-bin/cvsweb.cgi/src/gold/fileread.h.diff?cvsroot=src&r1=1.46&r2=1.47
http://sourceware.org/cgi-bin/cvsweb.cgi/src/gold/fileread.cc.diff?cvsroot=src&r1=1.69&r2=1.70
Comment 20 cvs-commit@gcc.gnu.org 2011-03-09 01:54:58 UTC
CVSROOT:	/cvs/src
Module name:	src
Branch: 	binutils-2_21-branch
Changes by:	ian@sourceware.org	2011-03-09 01:54:55

Modified files:
	gold           : ChangeLog fileread.cc fileread.h 

Log message:
	PR gold/12525
	* fileread.cc: #include <climits>.
	(GOLD_IOV_MAX): Define.
	(File_read::read_multiple): Limit number of entries by iov_max.
	* fileread.h (class File_read): Always set max_readv_entries to
	128.

Patches:
http://sourceware.org/cgi-bin/cvsweb.cgi/src/gold/ChangeLog.diff?cvsroot=src&only_with_tag=binutils-2_21-branch&r1=1.664.2.19&r2=1.664.2.20
http://sourceware.org/cgi-bin/cvsweb.cgi/src/gold/fileread.cc.diff?cvsroot=src&only_with_tag=binutils-2_21-branch&r1=1.68&r2=1.68.2.1
http://sourceware.org/cgi-bin/cvsweb.cgi/src/gold/fileread.h.diff?cvsroot=src&only_with_tag=binutils-2_21-branch&r1=1.45&r2=1.45.2.1
Comment 21 Ian Lance Taylor 2011-03-09 01:56:59 UTC
There's not much point to trying to use gold to build gcc until gold passes at least most of its tests.

The failure on basic_static_test looks like you don't have libc.a or libm.a--that is, it looks like gcc -static is always going to fail, whether using gold or the existing linker.  Is that correct?

I committed a patch which should fix the problem of passing too many values to readv.

I don't know what's going on with the other two errors.
Comment 22 Rainer Orth 2011-03-09 09:49:09 UTC
> --- Comment #21 from Ian Lance Taylor <ian at airs dot com> 2011-03-09 01:56:59 UTC ---
> There's not much point to trying to use gold to build gcc until gold passes at
> least most of its tests.

Ok.

> The failure on basic_static_test looks like you don't have libc.a or
> libm.a--that is, it looks like gcc -static is always going to fail, whether
> using gold or the existing linker.  Is that correct?

Right: starting from Solaris 10, static system libs are gone, and 64-bit
static libs didn't exist ever, even when 64-bit support was introduced
in Solaris 7.

> I committed a patch which should fix the problem of passing too many values to
> readv.

Thanks, I'll give it a try.

> I don't know what's going on with the other two errors.

I'll investigate as time permits.

	Rainer
Comment 23 Rainer Orth 2011-03-11 15:40:46 UTC
> --- Comment #21 from Ian Lance Taylor <ian at airs dot com> 2011-03-09 01:56:59 UTC ---
[...]
> I committed a patch which should fix the problem of passing too many values to
> readv.

That fixes all related failures, thanks.

> I don't know what's going on with the other two errors.

I'll see if I can find anything over the weekend.  This also blocks a
gcc bootstrap with gold.

	Rainer
Comment 24 Rainer Orth 2011-03-14 19:40:31 UTC
I've had a look at the two remaining errors (apart from not having
static system libs on newer Solaris releases):

gcctestdir/ld: internal error in override_version, at /vol/gnu/src/binutils/binutils-hg/gold/resolve.cc:61
collect2: ld returned 1 exit status
make[3]: *** [weak_test] Error 1

This can be reproduced with

gold-2.21.51 -o weak_test /usr/lib/crt1.o weak_test.o -lc 
gold-2.21.51: internal error in override_version, at /vol/gnu/src/binutils/binutils-hg/gold/resolve.cc:61

In override_version, I find:

  this->name_ = _iob
  this->version_ = SUNW_0.7
  version = SYSVABI_1.3

With pvs -dsvo /lib/libc.so.1, I find the following version info in libc:

/lib/libc.so.1 -        SUNW_0.7: _iob (960);
/lib/libc.so.1 -        SYSVABI_1.3: __iob (960);

and elfdump reveals a bit more about those symbols:

$ elfdump -s /lib/libc.so.1|grep _iob       
      [60]  0x00151818 0x000003c0  OBJT GLOB  D   40 .data          _iob
     [299]  0x00151818 0x000003c0  OBJT WEAK  D   41 .data          __iob

The other failure is

gcctestdir/ld: error: read-only segment has dynamic relocations
collect2: ld returned 1 exit status
make[3]: *** [two_file_shared_1_nonpic.so] Error 1

Can be reproduced with

gold-2.21.51 -G -z text -o two_file_shared_1_nonpic.so two_file_test_1.o two_file_test_1b.o 
gold-2.21.51: error: read-only segment has dynamic relocations

I suspect this happens because (32-bit) Solaris 2/x86 creates non-PIC
code without -fpic/-fPIC.

If so, the FN_PTRS_IN_SO_WITHOUT_PIC test in gold/configure.ac would
have to be updated, perhaps with a real test instead of a hardcoded
target list?

Strangely, gld 2.21 can link those objects, while ld can not.

I'm attaching them for inspection.

	Rainer
Comment 25 Rainer Orth 2011-03-14 19:42:47 UTC
Created attachment 5306 [details]
object files for failing two_file_shared_1_nonpic.so test
Comment 26 cvs-commit@gcc.gnu.org 2011-07-02 00:03:28 UTC
CVSROOT:	/cvs/src
Module name:	src
Changes by:	ian@sourceware.org	2011-07-02 00:03:25

Modified files:
	gold           : ChangeLog ehframe.cc i386.cc target.h x86_64.cc 

Log message:
	PR gold/12525
	* ehframe.cc (Eh_frame_hdr::get_fde_pc): Handle DW_EH_PE_datarel.
	Assert if we see DW_EH_PE_indirect.
	* target.h (Target::ehframe_datarel_base): New function.
	(Target::do_ehframe_datarel_base): New target function.
	* i386.cc (Target_i386::do_ehframe_datarel_base): New function.
	* x86_64.cc (Target_x86_64::do_ehframe_datarel_base): New
	function.

Patches:
http://sourceware.org/cgi-bin/cvsweb.cgi/src/gold/ChangeLog.diff?cvsroot=src&r1=1.780&r2=1.781
http://sourceware.org/cgi-bin/cvsweb.cgi/src/gold/ehframe.cc.diff?cvsroot=src&r1=1.20&r2=1.21
http://sourceware.org/cgi-bin/cvsweb.cgi/src/gold/i386.cc.diff?cvsroot=src&r1=1.133&r2=1.134
http://sourceware.org/cgi-bin/cvsweb.cgi/src/gold/target.h.diff?cvsroot=src&r1=1.60&r2=1.61
http://sourceware.org/cgi-bin/cvsweb.cgi/src/gold/x86_64.cc.diff?cvsroot=src&r1=1.131&r2=1.132
Comment 27 cvs-commit@gcc.gnu.org 2011-07-02 00:19:06 UTC
CVSROOT:	/cvs/src
Module name:	src
Changes by:	ian@sourceware.org	2011-07-02 00:19:04

Modified files:
	gold           : ChangeLog configure configure.ac 
	gold/testsuite : Makefile.am Makefile.in 

Log message:
	PR gold/12525
	* configure.ac: Test whether static linking works, setting
	the automake conditional HAVE_STATIC.
	* testsuite/Makefile.am: Disable tests using -static if
	HAVE_STATIC is not true.
	* configure, testsuite/Makefile.in: Rebuild.

Patches:
http://sourceware.org/cgi-bin/cvsweb.cgi/src/gold/ChangeLog.diff?cvsroot=src&r1=1.781&r2=1.782
http://sourceware.org/cgi-bin/cvsweb.cgi/src/gold/configure.diff?cvsroot=src&r1=1.66&r2=1.67
http://sourceware.org/cgi-bin/cvsweb.cgi/src/gold/configure.ac.diff?cvsroot=src&r1=1.63&r2=1.64
http://sourceware.org/cgi-bin/cvsweb.cgi/src/gold/testsuite/Makefile.am.diff?cvsroot=src&r1=1.168&r2=1.169
http://sourceware.org/cgi-bin/cvsweb.cgi/src/gold/testsuite/Makefile.in.diff?cvsroot=src&r1=1.177&r2=1.178
Comment 28 cvs-commit@gcc.gnu.org 2011-07-02 00:39:15 UTC
CVSROOT:	/cvs/src
Module name:	src
Changes by:	ian@sourceware.org	2011-07-02 00:39:13

Modified files:
	gold           : ChangeLog options.h 
	gold/testsuite : Makefile.am Makefile.in 

Log message:
	PR gold/12525
	* options.h (class General_options): Support -z notext.
	* testsuite/Makefile.am (two_file_shared_1_nonpic.so): Use
	-Wl,-z,notext.
	(two_file_shared_nonpic.so): Likewise.
	(two_file_shared_mixed.so): Likewise.
	(two_file_shared_mixed_1.so): Likewise.
	(weak_undef_lib_nonpic.so): Likewise.
	(alt/weak_undef_lib_nonpic.so): Likewise.
	(tls_test_shared_nonpic.so): Likewise.
	* testsuite/Makefile.in: Rebuild.

Patches:
http://sourceware.org/cgi-bin/cvsweb.cgi/src/gold/ChangeLog.diff?cvsroot=src&r1=1.782&r2=1.783
http://sourceware.org/cgi-bin/cvsweb.cgi/src/gold/options.h.diff?cvsroot=src&r1=1.162&r2=1.163
http://sourceware.org/cgi-bin/cvsweb.cgi/src/gold/testsuite/Makefile.am.diff?cvsroot=src&r1=1.169&r2=1.170
http://sourceware.org/cgi-bin/cvsweb.cgi/src/gold/testsuite/Makefile.in.diff?cvsroot=src&r1=1.178&r2=1.179
Comment 29 Ian Lance Taylor 2011-07-02 00:43:51 UTC
The failure of two_file_shared_1_nonpic.so is not very interesting.  It happens because on Solaris when gcc sees -shared it passes -z text to the linker.  GNU ld does not support -z text and simply ignores it, as it ignores all unrecognized -z options.  The gold linker does support -z text, which means to not permit dynamic relocations in the text segment.  This test is specifically testing that that works, so naturally it fails.

I just committed a patch to support -z notext, and to use it when appropriate, so this test should no longer fail on Solaris.

I also committed a patch to avoid testing with -static in cases where it does not work.
Comment 30 cvs-commit@gcc.gnu.org 2011-07-02 05:30:08 UTC
CVSROOT:	/cvs/src
Module name:	src
Changes by:	ian@sourceware.org	2011-07-02 05:30:00

Modified files:
	gold           : ChangeLog dynobj.cc dynobj.h resolve.cc 
	gold/testsuite : Makefile.am Makefile.in weak_alias_test_main.cc 
Added files:
	gold/testsuite : weak_alias_test.script weak_alias_test_5.cc 

Log message:
	PR gold/12525
	PR gold/12952
	* resolve.cc (Symbol::override_base_with_special): Don't override
	the version if the overriding symbol has a different name.
	* dynobj.cc (Versions::add_def): Add dynpool parameter.  Change
	all callers.  If we give an error about an undefined version,
	define the base version if necessary.
	* dynobj.h (class Versions): Update declaration.
	* testsuite/weak_alias_test_5.cc: New file.
	* testsuite/weak_alias_test.script: New file.
	* testsuite/weak_alias_test_main.cc: Check that versioned_symbol
	and versioned_alias have the right value, and call t2.
	* testsuite/Makefile.am (weak_alias_test_DEPENDENCIES): Add
	weak_alias_test_5.so.
	(weak_alias_test_LDADD): Likewise.
	(weak_alias_test_5_pic.o, weak_alias_test_5.so): New targets.
	* testsuite/Makefile.in: Rebuild.

Patches:
http://sourceware.org/cgi-bin/cvsweb.cgi/src/gold/ChangeLog.diff?cvsroot=src&r1=1.783&r2=1.784
http://sourceware.org/cgi-bin/cvsweb.cgi/src/gold/dynobj.cc.diff?cvsroot=src&r1=1.62&r2=1.63
http://sourceware.org/cgi-bin/cvsweb.cgi/src/gold/dynobj.h.diff?cvsroot=src&r1=1.45&r2=1.46
http://sourceware.org/cgi-bin/cvsweb.cgi/src/gold/resolve.cc.diff?cvsroot=src&r1=1.60&r2=1.61
http://sourceware.org/cgi-bin/cvsweb.cgi/src/gold/testsuite/weak_alias_test.script.diff?cvsroot=src&r1=NONE&r2=1.1
http://sourceware.org/cgi-bin/cvsweb.cgi/src/gold/testsuite/weak_alias_test_5.cc.diff?cvsroot=src&r1=NONE&r2=1.1
http://sourceware.org/cgi-bin/cvsweb.cgi/src/gold/testsuite/Makefile.am.diff?cvsroot=src&r1=1.170&r2=1.171
http://sourceware.org/cgi-bin/cvsweb.cgi/src/gold/testsuite/Makefile.in.diff?cvsroot=src&r1=1.179&r2=1.180
http://sourceware.org/cgi-bin/cvsweb.cgi/src/gold/testsuite/weak_alias_test_main.cc.diff?cvsroot=src&r1=1.1&r2=1.2
Comment 31 Ian Lance Taylor 2011-07-02 05:35:23 UTC
As far as I can tell, with the patch I just committed, all the issues in this bug report should now be fixed.  In any case this report has gotten rather complicated.  If there are any remaining issues on Solaris, please open a new bug report.  Thanks.
Comment 32 Ian Lance Taylor 2011-07-09 00:16:08 UTC
*** Bug 11748 has been marked as a duplicate of this bug. ***