Temporary patch to fix sparc64 relocation errors (was: Re: Using binutils-2.13 on sparc64-sun-solaris2.8 to build gcc-3.1.1 results in relocation errors)

[Michael J. Bond]

Brad Spencer wrote:

>After having no success with gcc-3.1 and binutils-2.12.1 on
>sparc64-sun-solaris2.8 (I used binutils-2.11.2 for this target), I've
>tried again with binutils-2.13 and gcc-3.1.1.  I've encountered the
>exact same problem when trying to link C++ programs.  If I swap out
>binutils-2.13 with binutils-2.11.2 (under a gcc-3.1.1 built for
>binutils-2.13) then linking works.
>
>My latest efforts have included trying to disable HAVE_AS_SPARC_UA_PCREL
>and HAVE_AS_SPARC_UA_PCREL_HIDDEN in gcc, but to no avail.
>Considering I can merely swap out the binutils (and even link
>libraries made with 2.13 and a 2.13-aware compiler), I suspect this is
>a binutils bug.  I post in the hopes that someone can lend me some
>insight.
>
>My next step is to start looking at the diffs between 2.11.2 and
>2.12.1 as far as bfd's relocation overflow detection goes.  Am I on
>the right track?  BTW, my latest work has been with a cross compiler,
>but it's no different than when using a native toolchain.
>
>Previous post follows:
>
>I've looked through the archives and the comments in gcc-3.1, and it
>looks like this might be some sort of new feature that doesn't quite
>work correctly.  If I configure gcc-3.1 on top of binutils-2.12.1,
>then when I link 64-bit objects, I get things to the effect of
>  
>
I'm guessing here but it may be that binutils-2.11 was accepting 32-bit 
relocations in situations that needed 64 and either silently converting 
to a 64-bit relocation or worse.

As a temporary solution I've changed the relocation that gcc generates 
on 64-bit sparc targets to always be 64-bit and it seems to work. This 
probably should only be a temporary thing and if possible the generation 
of exception pointers should become somewhat smarter on 64-bit sparc 
targets. I've attached the diffs for this temporary patch to gcc-3.2 to 
get it working with binutils-2.13. I'll go ahead and cross post it to 
the gcc patch list so hopefully someone will at least start looking at 
it closer.


-------------- next part --------------
--- gcc/config/sparc/sparc.h.orig	2002-09-13 10:29:59.400005000 -0400
+++ gcc/config/sparc/sparc.h	2002-09-12 16:46:58.770008000 -0400
@@ -2015,25 +2015,21 @@
 
    binutils 2.12 would emit a R_SPARC_DISP32 dynamic relocation if the
    symbol %r_disp32() is against was not local, but .hidden.  In that
-   case, we have to use DW_EH_PE_absptr for pic personality.
- 
-   binutils 2.13 seems to require a 64-bit relocation for TARGET_ARCH64.
-   This may not be the best long term solution, but it gets C++ apps
-   using libstdc++ working. */
+   case, we have to use DW_EH_PE_absptr for pic personality.  */
 #ifdef HAVE_AS_SPARC_UA_PCREL
 #ifdef HAVE_AS_SPARC_UA_PCREL_HIDDEN
 #define ASM_PREFERRED_EH_DATA_FORMAT(CODE,GLOBAL)			\
   (flag_pic								\
    ? (GLOBAL ? DW_EH_PE_indirect : 0) | DW_EH_PE_pcrel | DW_EH_PE_sdata4\
    : ((TARGET_ARCH64 && ! GLOBAL)					\
-      ? (DW_EH_PE_pcrel | DW_EH_PE_sdata4)				\
+      ? (DW_EH_PE_pcrel | DW_EH_PE_sdata8)				\
       : DW_EH_PE_absptr))
 #else
 #define ASM_PREFERRED_EH_DATA_FORMAT(CODE,GLOBAL)			\
   (flag_pic								\
    ? (GLOBAL ? DW_EH_PE_absptr : (DW_EH_PE_pcrel | DW_EH_PE_sdata4))	\
    : ((TARGET_ARCH64 && ! GLOBAL)					\
-      ? (DW_EH_PE_pcrel | DW_EH_PE_sdata4)				\
+      ? (DW_EH_PE_pcrel | DW_EH_PE_sdata8)				\
       : DW_EH_PE_absptr))
 #endif