Bug 7027 - 64-bit libstdc++.so fails to link on Solaris 11/SPARC: could not read symbols: Bad value
Summary: 64-bit libstdc++.so fails to link on Solaris 11/SPARC: could not read symbols...
Status: RESOLVED FIXED
Alias: None
Product: binutils
Classification: Unclassified
Component: ld (show other bugs)
Version: 2.20
: P2 normal
Target Milestone: ---
Assignee: unassigned
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2008-11-12 14:43 UTC by Rainer Orth
Modified: 2008-11-19 09:26 UTC (History)
2 users (show)

See Also:
Host: sparc-sun-solaris2.11
Target: sparc-sun-solaris2.11
Build: sparc-sun-solaris2.11
Last reconfirmed:


Attachments
Guess at how to handle local WPLT30 relocations for 64-bit sparc. (551 bytes, patch)
2008-11-14 09:18 UTC, Nick Clifton
Details | Diff
Another patch attempt (1.09 KB, patch)
2008-11-17 16:46 UTC, Nick Clifton
Details | Diff
problematic object file (10.85 KB, application/octet-stream)
2008-11-17 18:02 UTC, Rainer Orth
Details
object file that shows both the original and new problems (19.31 KB, application/octet-stream)
2008-11-17 18:13 UTC, Rainer Orth
Details
third try (431 bytes, patch)
2008-11-18 11:42 UTC, Nick Clifton
Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Rainer Orth 2008-11-12 14:43:45 UTC
Trying to build current gcc mainline with GNU ld 2.19 fails linking the 64-bit
libstdc++.so.  When I retried with binutils mainline, the problems persists:

% /vol/gcc/obj/binutils-2.19.50-g/ld/ld-new -V -G -dy -z text -m elf64_sparc -Y
P,/usr/lib/sparcv9 -rpath-link /usr/lib/sparcv9 -Qy -o .libs/libstdc++.so.6.0.11
-L/vol/gccsrc/obj/gcc-4.4.0-20081110/11-gcc-gld/sparc-sun-solaris2.11/sparcv9/libstdc++-v3/src
-L/vol/gccsrc/obj/gcc-4.4.0-20081110/11-gcc-gld/sparc-sun-solaris2.11/sparcv9/libstdc++-v3/src/.libs
-L/vol/gccsrc/obj/gcc-4.4.0-20081110/11-gcc-gld/sparc-sun-solaris2.11/sparcv9/libstdc++-v3/src
-L/vol/gccsrc/obj/gcc-4.4.0-20081110/11-gcc-gld/sparc-sun-solaris2.11/sparcv9/libstdc++-v3/src/.libs
-L/vol/gccsrc/obj/gcc-4.4.0-20081110/11-gcc-gld/./gcc/sparcv9
-L/usr/ccs/lib/sparcv9 -L/lib/sparcv9 -L/usr/lib/sparcv9
-L/vol/gccsrc/obj/gcc-4.4.0-20081110/11-gcc-gld/./gcc -L/usr/ccs/lib
-L/vol/gccsrc/obj/gcc-4.4.0-20081110/11-gcc-gld/./gcc/sparcv9
-L/usr/ccs/lib/sparcv9 -L/lib/sparcv9 -L/usr/lib/sparcv9
-L/vol/gccsrc/obj/gcc-4.4.0-20081110/11-gcc-gld/./gcc -L/usr/ccs/lib
/vol/gccsrc/obj/gcc-4.4.0-20081110/11-gcc-gld/./gcc/sparcv9/crti.o
/usr/ccs/lib/sparcv9/values-Xa.o
/vol/gccsrc/obj/gcc-4.4.0-20081110/11-gcc-gld/./gcc/sparcv9/crtbegin.o
.libs/atomic.o .libs/bitmap_allocator.o .libs/pool_allocator.o
.libs/mt_allocator.o .libs/codecvt.o .libs/compatibility.o .libs/complex_io.o
.libs/ctype.o .libs/debug.o .libs/functexcept.o .libs/hash.o .libs/hash_c++0x.o
.libs/globals_io.o .libs/hashtable.o .libs/hashtable_c++0x.o .libs/ios.o
.libs/ios_failure.o .libs/ios_init.o .libs/ios_locale.o .libs/limits.o
.libs/limits_c++0x.o .libs/list.o .libs/debug_list.o .libs/locale.o
.libs/locale_init.o .libs/locale_facets.o .libs/localename.o .libs/stdexcept.o
.libs/strstream.o .libs/system_error.o .libs/tree.o .libs/allocator-inst.o
.libs/concept-inst.o .libs/fstream-inst.o .libs/ext-inst.o .libs/ios-inst.o
.libs/iostream-inst.o .libs/istream-inst.o .libs/istream.o .libs/locale-inst.o
.libs/misc-inst.o .libs/ostream-inst.o .libs/sstream-inst.o
.libs/streambuf-inst.o .libs/streambuf.o .libs/string-inst.o
.libs/valarray-inst.o .libs/wlocale-inst.o .libs/wstring-inst.o .libs/mutex.o
.libs/condition_variable.o .libs/chrono.o .libs/thread.o .libs/atomicity.o
.libs/codecvt_members.o .libs/collate_members.o .libs/ctype_members.o
.libs/messages_members.o .libs/monetary_members.o .libs/numeric_members.o
.libs/time_members.o .libs/basic_file.o .libs/c++locale.o .libs/parallel_list.o
.libs/parallel_settings.o --whole-archive ../libmath/.libs/libmath.a
../libsupc++/.libs/libsupc++convenience.a --no-whole-archive -lm -lgcc_s
/vol/gccsrc/obj/gcc-4.4.0-20081110/11-gcc-gld/./gcc/sparcv9/crtend.o
/vol/gccsrc/obj/gcc-4.4.0-20081110/11-gcc-gld/./gcc/sparcv9/crtn.o -O1 -z relro
--gc-sections --version-script=libstdc++-symbols.ver -soname libstdc++.so.6
GNU ld (GNU Binutils) 2.19.50.20081111
  Supported emulations:
   elf32_sparc
   elf64_sparc
.libs/atomic.o: could not read symbols: Bad value

Tracking this down (with an unoptimize ld compiled with -g only, because gdb
couldn't proper handle the -g -O2 binary), I found that bfd_set_error
(bfd_error_bad_value) is called from here:

#0  bfd_set_error (error_tag=bfd_error_bad_value) at
/vol/gnu/src/binutils/binutils-dist/bfd/bfd.c:425
#1  0x0008d130 in _bfd_sparc_elf_check_relocs (abfd=0x1dc510, info=0x19d978,
sec=0x1f6a20, relocs=0x1fdc10) at
/vol/gnu/src/binutils/binutils-dist/bfd/elfxx-sparc.c:1335
#2  0x000c4210 in elf_link_add_object_symbols (abfd=0x1dc510, info=0x19d978) at
/vol/gnu/src/binutils/binutils-dist/bfd/elflink.c:4722
#3  0x000c4dc8 in bfd_elf_link_add_symbols (abfd=0x1dc510, info=0x19d978) at
/vol/gnu/src/binutils/binutils-dist/bfd/elflink.c:5044
#4  0x0002e604 in load_symbols (entry=0x19dfc8, place=0xffbfe8d0) at
/vol/gnu/src/binutils/binutils-dist/ld/ldlang.c:2599
#5  0x0002f6b8 in open_input_bfds (s=0x19dfc8, force=0) at
/vol/gnu/src/binutils/binutils-dist/ld/ldlang.c:3028
#6  0x00037798 in lang_process () at
/vol/gnu/src/binutils/binutils-dist/ld/ldlang.c:6112
#7  0x0003ce4c in main (argc=114, argv=0xffbfea7c) at
/vol/gnu/src/binutils/binutils-dist/ld/ldmain.c:453

I.e. from bfd/elfxx-sparc.c (_bfd_sparc_elf_check_relocs), l. 1335.  At that
point, r_type = 18 (R_SPARC_WPLT30) and readelf on the problematic object
file reveals

% readelf -r .libs/atomic.o |grep R_SPARC_WPLT30
000000000014  000e00000012 R_SPARC_WPLT30    0000000000000000 .text + 0
000000000008  001800000012 R_SPARC_WPLT30    0000000000000000
atomic_flag_clear_expl + 0
000000000008  001b00000012 R_SPARC_WPLT30    0000000000000000
atomic_flag_test_and_s + 0
000000000008  001b00000012 R_SPARC_WPLT30    0000000000000000
atomic_flag_test_and_s + 0

It seems that a workaround similar to the ! ABI_64_P() case may be needed
for the 64-bit case as well.
Comment 1 Nick Clifton 2008-11-14 09:18:50 UTC
Created attachment 3062 [details]
Guess at how to handle local WPLT30 relocations for 64-bit sparc.
Comment 2 Nick Clifton 2008-11-14 09:19:46 UTC
Hi Rainer,

  I am not familiar with the Sparc architecture, but I have uploaded a possible
patch which might fix the problem you discovered.  Please could you try it out
and let me know if it really works ?

Cheers
  Nick
Comment 3 Rainer Orth 2008-11-14 14:15:39 UTC
Subject: Re:  64-bit libstdc++.so fails to link on Solaris 11/SPARC: could not read symbols: Bad value

Hi Nick,

>   I am not familiar with the Sparc architecture, but I have uploaded a possible

me, neither, I just happen to test regularly on Solaris :-)

> patch which might fix the problem you discovered.  Please could you try it out
> and let me know if it really works ?

Unfortunately, it doesn't:

+ 	      /* The Solaris native assembler will generate a WPLT30
+ 		 reloc for a local symbol if you assemble a call from
+ 		 one section to another when using -K pic.  We treat
+ 		 it as WDISP30.  */
+ 	      if ((! ABI_64_P (abfd) && ELF32_R_TYPE (rel->r_info) == R_SPARC_PLT32)
+ 		  || (ABI_64_P (abfd) && ELF32_R_TYPE (rel->r_info) == R_SPARC_PLT64))
+ 		goto r_sparc_plt32;

The ABI_64_P() part doesn't trigger since ELF32_R_TYPE (rel->r_info) is 18
(i.e. R_SPARC_WPLT30) at this point.  I don't really have an idea why/if
the 32-bit part works.

I suppose it was added back in 1994 by Ian:

Fri Oct 21 17:13:07 1994  Ian Lance Taylor  <ian@sanguine.cygnus.com>

[...]
	* elf32-sparc.c (elf_sparc_howto_table): Fix R_SPARC_PC22 by
[...]
	(elf32_sparc_relocate_section): For a GOT reloc against a global
	symbol when no dynamic object was seen, initialize the contents of
	the .got section.  For a GOT reloc against a local symbol, only
	create a R_SPARC_RELATIVE reloc when generating a shared object.
	Treat a R_SPARC_WPLT30 reloc against a symbol for which we did not
	create a PLT entry as a R_SPARC_WDISP30 reloc.

but the mainling list archive on www.sourceware.org doesn't go that far
back.

Perhaps he can shed some light on this.

	Rainer
Comment 4 Nick Clifton 2008-11-14 14:51:56 UTC
Subject: Re:  64-bit libstdc++.so fails to link on Solaris	11/SPARC:
 could not read symbols: Bad value

Hi Rainer,

> + 	      if ((! ABI_64_P (abfd) && ELF32_R_TYPE (rel->r_info) == R_SPARC_PLT32)
> + 		  || (ABI_64_P (abfd) && ELF32_R_TYPE (rel->r_info) == R_SPARC_PLT64))

> The ABI_64_P() part doesn't trigger since ELF32_R_TYPE (rel->r_info) is 18
> (i.e. R_SPARC_WPLT30) at this point.  I don't really have an idea why/if
> the 32-bit part works.

As a matter of interest if you change this to:

   if ((! ABI_64_P (abfd) && ELF32_R_TYPE (rel->r_info) == R_SPARC_PLT32)
    || (ABI_64_P (abfd) && ELF32_R_TYPE (rel->r_info) == R_SPARC_WPLT30))

does the patch then work ?  (I agree that the 32-bit case does seem 
rather mysterious).

Cheers
   Nick

Comment 5 Rainer Orth 2008-11-14 15:09:08 UTC
Subject: Re:  64-bit libstdc++.so fails to link on Solaris 11/SPARC: could not read symbols: Bad value

Hi Nick,

> As a matter of interest if you change this to:
>
>    if ((! ABI_64_P (abfd) && ELF32_R_TYPE (rel->r_info) == R_SPARC_PLT32)
>     || (ABI_64_P (abfd) && ELF32_R_TYPE (rel->r_info) == R_SPARC_WPLT30))
>
> does the patch then work ?  (I agree that the 32-bit case does seem
> rather mysterious).

unfortunately not: this time ld SEGVs:

/vol/gcc/obj/binutils-2.19.50-g/ld/ld-new: warning: section `.bss' type changed to PROGBITS
/vol/gcc/obj/binutils-2.19.50-g/ld/ld-new: BFD (GNU Binutils) 2.19.50.20081111 assertion fail /vol/gnu/src/binutils/binutils-dist/bfd/elfxx-sparc.c:2765
Segmentation Fault

#0  0x00091024 in _bfd_sparc_elf_relocate_section (output_bfd=0x1c5f10, info=0x19da08, input_bfd=0x1dc5a0, input_section=0x1f6ab0, contents=0x1082948 "\235ã¿@\20560\002\003", relocs=0x1fdca0, local_syms=0x753920, local_sections=0xfa3c98) at /vol/gnu/src/binutils/binutils-dist/bfd/elfxx-sparc.c:2768
#1  0x000d4b9c in elf_link_input_bfd (finfo=0xffbfe880, input_bfd=0x1dc5a0) at /vol/gnu/src/binutils/binutils-dist/bfd/elflink.c:9327
#2  0x000d7f84 in bfd_elf_final_link (abfd=0x1c5f10, info=0x19da08) at /vol/gnu/src/binutils/binutils-dist/bfd/elflink.c:10452
#3  0x00040958 in ldwrite () at /vol/gnu/src/binutils/binutils-dist/ld/ldwrite.c:567
#4  0x0003cec0 in main (argc=114, argv=0xffbfea7c) at /vol/gnu/src/binutils/binutils-dist/ld/ldmain.c:462

At l. 2768 of elfxx-sparc.c (_bfd_sparc_elf_relocate_section), h is NULL,
so

	  if (h->plt.offset == (bfd_vma) -1 || htab->splt == NULL)
	    {
	      /* We didn't make a PLT entry for this symbol.  This
		 happens when statically linking PIC code, or when
		 using -Bsymbolic.  */
	      break;
	    }

crashes when dereferencing it.

If I adapt the check immediately before

@@ -2751,19 +2751,12 @@
 	  /* Relocation is to the entry for this symbol in the
 	     procedure linkage table.  */

-	  if (! ABI_64_P (output_bfd))
-	    {
-	      /* The Solaris native assembler will generate a WPLT30 reloc
-		 for a local symbol if you assemble a call from one
-		 section to another when using -K pic.  We treat it as
-		 WDISP30.  */
-	      if (h == NULL)
-		break;
-	    }
-	  else
-	    {
-	      BFD_ASSERT (h != NULL);
-	    }
+	  /* The Solaris native assembler will generate a WPLT30 reloc
+	     for a local symbol if you assemble a call from one
+	     section to another when using -K pic.  We treat it as
+	     WDISP30.  */
+	  if (h == NULL)
+	    break;

 	  if (h->plt.offset == (bfd_vma) -1 || htab->splt == NULL)
 	    {

I still get the "section `.bss' type changed to PROGBITS" warning, but at
least a libstdc++.so is produced.

I'm now continuting the GCC bootstrap and will run the testsuite see if
this seems to work.

	Rainer
Comment 6 Ian Lance Taylor 2008-11-16 18:33:44 UTC
I didn't write the code in question.  The code I added was simple: if there is a
R_SPARC_WPLT30 reloc against a symbol for which no PLT entry was created, we
handle it as a R_SPARC_WDISP30 reloc.  That is straightforward and obviously
correct.  It is correct whether the object file is 32-bit or 64-bit.  I haven't
looked at the 64-bit SPARC ELF format, and I'm not sure what all the relocs in
that case are.  But it seems clear that
    if (h == NULL && ELFXX_R_TYPE (rel->r_info) == R_SPARC_WPLT30))
_bfd_sparc_elf_check_relocs should simply return TRUE.

The same case must also be handled in _bfd_sparc_elf_relocate_section.
Comment 7 Nick Clifton 2008-11-17 16:46:35 UTC
Created attachment 3065 [details]
Another patch attempt
Comment 8 Nick Clifton 2008-11-17 16:47:47 UTC
Hi Rainer,

  OK taking Ian's comments into account I have uploaded another attempt at a
patch for this problem.  Please could you try it out and let me know if it is
any good ?

Cheers
  Nick
Comment 9 Rainer Orth 2008-11-17 17:29:45 UTC
Subject: Re:  64-bit libstdc++.so fails to link on Solaris 11/SPARC: could not read symbols: Bad value

Hi Nick,

>   OK taking Ian's comments into account I have uploaded another attempt at a
> patch for this problem.  Please could you try it out and let me know if it is
> any good ?

unfortunately, ld SEGVs now here:

#0  0x0008d19c in _bfd_sparc_elf_check_relocs (abfd=0x1dc518, info=0x19d980, sec=0x1f6a28, relocs=0x1fdc18) at /vol/gnu/src/binutils/binutils-dist/bfd/elfxx-sparc.c:1348
#1  0x000c4214 in elf_link_add_object_symbols (abfd=0x1dc518, info=0x19d980) at /vol/gnu/src/binutils/binutils-dist/bfd/elflink.c:4722
#2  0x000c4dcc in bfd_elf_link_add_symbols (abfd=0x1dc518, info=0x19d980) at /vol/gnu/src/binutils/binutils-dist/bfd/elflink.c:5044
#3  0x0002e604 in load_symbols (entry=0x19dfd0, place=0xffbfe8d0) at /vol/gnu/src/binutils/binutils-dist/ld/ldlang.c:2599
#4  0x0002f6b8 in open_input_bfds (s=0x19dfd0, force=0) at /vol/gnu/src/binutils/binutils-dist/ld/ldlang.c:3028
#5  0x00037798 in lang_process () at /vol/gnu/src/binutils/binutils-dist/ld/ldlang.c:6112
#6  0x0003ce4c in main (argc=114, argv=0xffbfea7c) at /vol/gnu/src/binutils/binutils-dist/ld/ldmain.c:453

On l.1348 of elfxx-sparc.c (_bfd_sparc_elf_check_relocs), h is NULL.

	Rainer
Comment 10 Nick Clifton 2008-11-17 17:41:46 UTC
Subject: Re:  64-bit libstdc++.so fails to link on Solaris	11/SPARC:
 could not read symbols: Bad value

Hi Rainer,

> unfortunately, ld SEGVs now here:
> 
> #0  0x0008d19c in _bfd_sparc_elf_check_relocs (abfd=0x1dc518, info=0x19d980, sec=0x1f6a28, relocs=0x1fdc18) at /vol/gnu/src/binutils/binutils-dist/bfd/elfxx-sparc.c:1348

Doh.  Thinko in the patch.  Please change:

   case R_SPARC_WPLT30:
     /* The Solaris native assembler will generate a WPLT30
        reloc for a local symbol if you assemble a call from
        one section to another when using -K pic.  We treat
        it as WDISP30.  */
     break;

to:

   case R_SPARC_WPLT30:
     /* The Solaris native assembler will generate a WPLT30
        reloc for a local symbol if you assemble a call from
        one section to another when using -K pic.  We treat
        it as WDISP30.  */
     return TRUE;

(Only the last line has changed).

Cheers
   Nick
Comment 11 Rainer Orth 2008-11-17 17:48:42 UTC
Subject: Re:  64-bit libstdc++.so fails to link on Solaris 11/SPARC: could not read symbols: Bad value

Hi Nick,

> (Only the last line has changed).

done, but not much better either: at first I get a lot of assertion
failures

GNU ld (GNU Binutils) 2.19.50.20081111
  Supported emulations:
   elf32_sparc
   elf64_sparc
/vol/gccsrc/obj/binutils-2.19.50-g/ld/ld-new: warning: section `.bss' type changed to PROGBITS
/vol/gccsrc/obj/binutils-2.19.50-g/ld/ld-new: BFD (GNU Binutils) 2.19.50.20081111 assertion fail /vol/gnu/src/binutils/binutils-dist/bfd/elfxx-sparc.c:2701
/vol/gccsrc/obj/binutils-2.19.50-g/ld/ld-new: BFD (GNU Binutils) 2.19.50.20081111 assertion fail /vol/gnu/src/binutils/binutils-dist/bfd/elfxx-sparc.c:2701
/vol/gccsrc/obj/binutils-2.19.50-g/ld/ld-new: BFD (GNU Binutils) 2.19.50.20081111 assertion fail /vol/gnu/src/binutils/binutils-dist/bfd/elfxx-sparc.c:2701
/vol/gccsrc/obj/binutils-2.19.50-g/ld/ld-new: BFD (GNU Binutils) 2.19.50.20081111 assertion fail /vol/gnu/src/binutils/binutils-dist/bfd/elfxx-sparc.c:2701
/vol/gccsrc/obj/binutils-2.19.50-g/ld/ld-new: BFD (GNU Binutils) 2.19.50.20081111 assertion fail /vol/gnu/src/binutils/binutils-dist/bfd/elfxx-sparc.c:2664
[1838 assertion failures total ...]

Program received signal SIGSEGV, Segmentation fault.
0x00090d60 in _bfd_sparc_elf_relocate_section (output_bfd=0x1c5ea0, info=0x19d998, input_bfd=0x391be8, input_section=0x3b80c0, contents=0x1080538 "\235ã¿@\222\020", relocs=0x3c62d8, local_syms=0xc69be8, local_sections=0xa08fb0) at /vol/gnu/src/binutils/binutils-dist/bfd/elfxx-sparc.c:2703
(gdb) p local_got_offsets
$1 = (bfd_vma *) 0x0

	Rainer
Comment 12 Nick Clifton 2008-11-17 17:54:38 UTC
Subject: Re:  64-bit libstdc++.so fails to link on Solaris	11/SPARC:
 could not read symbols: Bad value

Hi Rainer,

> done, but not much better either: at first I get a lot of assertion
> failures

Ok, this is going nowhere.  Is it possible for you to create a small 
testcase that reproduces the problem ?  Say just a single object file 
that you try to link ?  If so then please can you upload it to the issue 
along with a description of the linker command line used and I will try 
to reproduce the problem locally.

Cheers
   Nick

Comment 13 Rainer Orth 2008-11-17 18:02:51 UTC
Created attachment 3068 [details]
problematic object file
Comment 14 Rainer Orth 2008-11-17 18:13:01 UTC
Created attachment 3069 [details]
object file that shows both the original and new problems
Comment 15 Rainer Orth 2008-11-17 18:13:51 UTC
Subject: Re:  64-bit libstdc++.so fails to link on Solaris 11/SPARC: could not read symbols: Bad value

Hi Nick,

> Ok, this is going nowhere.  Is it possible for you to create a small 
> testcase that reproduces the problem ?  Say just a single object file 
> that you try to link ?  If so then please can you upload it to the issue 
> along with a description of the linker command line used and I will try 
> to reproduce the problem locally.

I've just uploaded badval.o.

If I try to link it into a shared library with

% ld -G -m elf64_sparc -o badval.so badval.o

using the original gld 2.19, I get

badval.o: could not read symbols: Bad value

With ld patched with the latest elfxx-sparc.c, I get

/vol/gcc/obj/binutils-2.19.50-g/ld/ld-new: BFD (GNU Binutils) 2.19.50.20081111 assertion fail /vol/gnu/src/binutils/binutils-dist/bfd/elfxx-sparc.c:2701
Segmentation Fault

	Rainer
Comment 16 Nick Clifton 2008-11-18 11:42:36 UTC
Created attachment 3072 [details]
third try
Comment 17 Nick Clifton 2008-11-18 11:45:23 UTC
Hi Rainer,

  OK, I have uploaded a third patch for you to try.  This one works(1) for me
although to be honest I do not really see how it is different from the second
patch.  Anyway give it a whirl and see how you go.

Cheers
   Nick

(1) Where "works" means that the linker does not complain and a binary is
produced.  I cannot tell you if the binary is actually functional.
Comment 18 Rainer Orth 2008-11-18 13:05:38 UTC
Subject: Re:  64-bit libstdc++.so fails to link on Solaris 11/SPARC: could not read symbols: Bad value

Hi Nick,

>   OK, I have uploaded a third patch for you to try.  This one works(1) for me
> although to be honest I do not really see how it is different from the second
> patch.  Anyway give it a whirl and see how you go.
> 
> Cheers
>    Nick
> 
> (1) Where "works" means that the linker does not complain and a binary is
> produced.  I cannot tell you if the binary is actually functional.

this one looks quite good: I can now successfully link the 64-bit
libstdc++.so.  Unfortunately, regtesting the resulting GCC build is
currently hampered by the following warning:

/vol/gcc/obj/binutils-2.19.50-g/ld/ld-new: warning: section `.bss' type changed to PROGBITS

This is harmless during the build, but many testcases (not only c++ and
libstdc++-v3) fail due to the unexpected message.

Thanks.
	Rainer
Comment 19 Nick Clifton 2008-11-18 14:07:33 UTC
Subject: Re:  64-bit libstdc++.so fails to link on Solaris	11/SPARC:
 could not read symbols: Bad value

Hi Rainer,

> Unfortunately, regtesting the resulting GCC build is
> currently hampered by the following warning:
> 
> /vol/gcc/obj/binutils-2.19.50-g/ld/ld-new: warning: section `.bss' type changed to PROGBITS
> 
> This is harmless during the build, but many testcases (not only c++ and
> libstdc++-v3) fail due to the unexpected message.

I think that this is a separate problem, rather than fallout from the 
patch.  Nevertheless it would be good to track it down.  Can you create 
a small testcase that reproduces it ?

Cheers
   Nick


Comment 20 Rainer Orth 2008-11-18 14:10:06 UTC
Subject: Re:  64-bit libstdc++.so fails to link on Solaris 11/SPARC: could not read symbols: Bad value

Hi Nick,

> I think that this is a separate problem, rather than fallout from the 

certainly.

> patch.  Nevertheless it would be good to track it down.  Can you create 
> a small testcase that reproduces it ?

I'll try.  First of all, I need to understand what the warning is all
about.

	Rainer
Comment 21 Nick Clifton 2008-11-18 14:21:10 UTC
Subject: Re:  64-bit libstdc++.so fails to link on Solaris	11/SPARC:
 could not read symbols: Bad value

Hi Rainer,

> I'll try.  First of all, I need to understand what the warning is all
> about.

Oh, well the "progbits" attribute indicates that the section contains 
data values, but the .bss section should in theory be completely empty 
and just initialized with zero bytes when the program is loaded into 
memory.  (ie its type should be NOBITS).

What is probably happening is that one or more of your input object 
files has a .bss section with the wrong attributes.  Why that should be 
is currently a mystery, but first we need to locate those object files 
(or else demonstrate that the problem has some other cause).

Cheers
   Nick


Comment 22 Rainer Orth 2008-11-18 14:41:07 UTC
Subject: Re:  64-bit libstdc++.so fails to link on Solaris 11/SPARC: could not read symbols: Bad value

Hi Nick,

> Oh, well the "progbits" attribute indicates that the section contains 
> data values, but the .bss section should in theory be completely empty 
> and just initialized with zero bytes when the program is loaded into 
> memory.  (ie its type should be NOBITS).

ok, understood.

> What is probably happening is that one or more of your input object 
> files has a .bss section with the wrong attributes.  Why that should be 
> is currently a mystery, but first we need to locate those object files 
> (or else demonstrate that the problem has some other cause).

Every single one of the libstdc++ object files is affected.  E.g.

% readelf -S --wide .libs/wstring-inst.o |grep -A1 '\.bss'
  [191] .bss._ZZL18__gthread_active_pvE21__gthread_active_once PROGBITS        0000000000000000 0205a8 000020 00  WA  0   0  8
  [192] .data._ZZL18__gthread_active_pvE22__gthread_active_mutex PROGBITS        0000000000000000 0205c8 000018 00  WA  0   0  8

Looking at the assembler source, I find:

	.section	".bss._ZZL18__gthread_active_pvE21__gthread_active_once",#alloc,#write
	.align 8
	.type	_ZZL18__gthread_active_pvE21__gthread_active_once, #object
	.size	_ZZL18__gthread_active_pvE21__gthread_active_once, 32
_ZZL18__gthread_active_pvE21__gthread_active_once:
	.skip 32

If I assemble the same source file with gas 2.19, I get

  [ 3] .bss              NOBITS          00000000 00003c 000000 00  WA  0   0  1
  [338] .bss._ZZL18__gthread_active_pvE21__gthread_active_once NOBITS          00000000 01a988 000020 00  WA  0   0  8

	Rainer
Comment 23 Nick Clifton 2008-11-18 15:11:54 UTC
Subject: Re:  64-bit libstdc++.so fails to link on Solaris	11/SPARC:
 could not read symbols: Bad value

Hi Rainer,

> Every single one of the libstdc++ object files is affected.  E.g.
> 
> % readelf -S --wide .libs/wstring-inst.o |grep -A1 '\.bss'
>   [191] .bss._ZZL18__gthread_active_pvE21__gthread_active_once PROGBITS        0000000000000000 0205a8 000020 00  WA  0   0  8

> If I assemble the same source file with gas 2.19, I get
> 
>   [ 3] .bss              NOBITS          00000000 00003c 000000 00  WA  0   0  1
>   [338] .bss._ZZL18__gthread_active_pvE21__gthread_active_once NOBITS          00000000 01a988 000020 00  WA  0   0  8

So, are you saying that assembling with gas v2.19 fixes the problem ? 
If so, can we close the PR (and apply the patch) ?

Cheers
   Nick

Comment 24 Rainer Orth 2008-11-18 18:23:19 UTC
Subject: Re:  64-bit libstdc++.so fails to link on Solaris 11/SPARC: could not read symbols: Bad value

Hi Nick,

> So, are you saying that assembling with gas v2.19 fixes the problem ? 

indeed: either it's a Sun as bug or gcc makes an assumption not borne out
by documentation (but held by gas).  I'm still trying to determine which it
is.

> If so, can we close the PR (and apply the patch) ?

Sure, thanks alot for your help.

	Rainer
Comment 25 Nick Clifton 2008-11-19 09:26:57 UTC
Hi Rainer,

  OK - I have checked in the patch along with this changelog entry.

Cheers
  Nick

bfd/ChangeLog
	PR 7027
	* elfxx-sparc.c (_bfd_sparc_elf_check_relocs): Treat WPLT30 relocs
	against local symbols in 64-bit binaries as if they were WDISP30
	relocs.
	(_bfd_sparc_elf_relocate_section): Likewise.
Comment 26 Rainer Orth 2008-11-19 17:08:59 UTC
Subject: Re:  64-bit libstdc++.so fails to link on Solaris 11/SPARC: could not read symbols: Bad value

Hi Nick,

>   OK - I have checked in the patch along with this changelog entry.

great, thanks a lot for all your help.

	Rainer