bug-binutils
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Bug ld/7027] 64-bit libstdc++.so fails to link on Solaris 11/SPARC: cou


From: ro at TechFak dot Uni-Bielefeld dot DE
Subject: [Bug ld/7027] 64-bit libstdc++.so fails to link on Solaris 11/SPARC: could not read symbols: Bad value
Date: 14 Nov 2008 14:15:39 -0000

------- Additional Comments From ro at TechFak dot Uni-Bielefeld dot DE  
2008-11-14 14:15 -------
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  <address@hidden>

[...]
        * 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


-- 


http://sourceware.org/bugzilla/show_bug.cgi?id=7027

------- You are receiving this mail because: -------
You are on the CC list for the bug, or are watching someone who is.




reply via email to

[Prev in Thread] Current Thread [Next in Thread]