Summary: | gold SEGV linking libgcc_s.so.1 on Solaris 11/x86 | ||
---|---|---|---|
Product: | binutils | Reporter: | Rainer Orth <ro> |
Component: | gold | Assignee: | Ian Lance Taylor <ian> |
Status: | RESOLVED FIXED | ||
Severity: | normal | CC: | Daniel.Davies |
Priority: | P2 | ||
Version: | 2.22 | ||
Target Milestone: | --- | ||
Host: | Target: | ||
Build: | Last reconfirmed: | ||
Attachments: |
Possible patch
object files for failing two_file_shared_1_nonpic.so test |
Description
Rainer Orth
2011-03-01 13:18:08 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 #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 Yes, gold should recognize -dy. That's a bug. 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 #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 #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 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 #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 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 #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
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 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 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.
"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 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 #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
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 #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
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 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 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 #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 #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 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 Created attachment 5306 [details]
object files for failing two_file_shared_1_nonpic.so test
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 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 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 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. 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 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. *** Bug 11748 has been marked as a duplicate of this bug. *** |