RE: solaris, collect2 and ld

RE: solaris, collect2 and ld

[Drury Tim]

Thanks for all the help guys....

> gcc cc1/as generates illegal relocation code, that solaris ld passes
> through to the final target. ("uaword" instead of "word").

I spent a little time figuring out how to compile the .cc file
to a .s.  I finally got it going and I found plenty of "uawords"
in prims.s.  I compiled all the .cc files in the /libjava directory
into .s's and they all had "uawords".  I'm not sure if this is
the problem, but it could be because prims.lo is the first file
listed in that huge list of .lo's that die during building.
Recall,

c++ -shared  prims.lo jni.lo exception.lo gnu/gcj/convert/BytesToUnicode.lo
gnu/gcj/convert/Convert.lo gnu/gcj/convert/Input_8859_1.lo
gnu/gcj/convert/Input_EUCJIS.lo gnu/gcj/convert/Input_JavaSrc.lo
gnu/gcj/convert/Input_SJIS.lo gnu/gcj/convert/Input_UTF8.lo
gnu/gcj/convert/Output_8859_1.lo gnu/gcj/convert/Output_EUCJIS.lo
gnu/gcj/convert/Output_JavaSrc.lo gnu/gcj/convert/Output_SJIS.lo 
< lots of .lo files deleted >
java/lang/s_scalbn.lo java/lang/sf_rint.lo java/lang/k_cos.lo
java/lang/s_sin.lo boehm.lo posix-threads.lo  -lc  -Wl,-soname
-Wl,libgcj.so.0 -o .libs/libgcj.so.0.0.0
prims.lo: could not read symbols: Bad value
collect2: ld returned 1 exit status
gmake[2]: *** [libgcj.la] Error 1

> The result when linking is that the written relocation addresses gets
> the high byte zeroed. We went nearly mad at trying to find 
> this bug. :)

I wonder if I can find that huge build list in the Makefile and
move prims.lo further in the list to see if any other modules die?

I'm pretty hell-bent on getting this thing built, but I'm really
getting frustrated now.

Also, I forgot to mention earlier that when I built egcs, I used
the option in the "compile" portion of the README that builds
without debugging info.  I needed this because of disk space 
constraints.  I wonder if everyone else is just doing "gmake bootstrap"?

-tim

Re: solaris, collect2 and ld (patch)

[Mirar]

> I spent a little time figuring out how to compile the .cc file
> to a .s.  I finally got it going and I found plenty of "uawords"

I mostly use --save-temps, inserted somewhere at CFLAGS in the Makefile. :-)

Try this patch to egcs/gcc:

mistel% diff -u egcs-19990517/gcc/config/sparc/sol2.h egcs-19990517/gcc/config/sparc/sol2.h.old  
--- egcs-19990517/gcc/config/sparc/sol2.h       Fri Jun 18 17:43:07 1999
+++ egcs-19990517/gcc/config/sparc/sol2.h.old   Fri Jun 18 17:42:44 1999
@@ -82,9 +82,9 @@
 /* Use .uahalf/.uaword so packed structure members don't generate
    assembler errors when using the native assembler.  */
 #undef ASM_SHORT
-#define ASM_SHORT ".half"
+#define ASM_SHORT ".uahalf"
 #undef ASM_LONG
-#define ASM_LONG ".word"
+#define ASM_LONG ".uaword"
 
 /* This is how to output a definition of an internal numbered label where
    PREFIX is the class of label and NUM is the number within the class.  */
---- end diff -----

/Mirar

Re: solaris, collect2 and ld (patch)

[Mirar]

> mistel% diff -u egcs-19990517/gcc/config/sparc/sol2.h egcs-19990517/gcc/config/sparc/sol2.h.old  

Ups, wrong argument order...

mistel% diff -u egcs-19990517/gcc/config/sparc/sol2.h.old egcs-19990517/gcc/config/sparc/sol2.h 
--- egcs-19990517/gcc/config/sparc/sol2.h.old   Fri Jun 18 17:42:44 1999
+++ egcs-19990517/gcc/config/sparc/sol2.h       Fri Jun 18 17:43:07 1999
@@ -82,9 +82,9 @@
 /* Use .uahalf/.uaword so packed structure members don't generate
    assembler errors when using the native assembler.  */
 #undef ASM_SHORT
-#define ASM_SHORT ".uahalf"
+#define ASM_SHORT ".half"
 #undef ASM_LONG
-#define ASM_LONG ".uaword"
+#define ASM_LONG ".word"
 
 /* This is how to output a definition of an internal numbered label where
    PREFIX is the class of label and NUM is the number within the class.  */
mistel% 

Re: solaris, collect2 and ld (patch)

[Jeffrey A Law]

  In message < 82so7p33y6.fsf@jms.idonex.se >you write:
  > > mistel% diff -u egcs-19990517/gcc/config/sparc/sol2.h egcs-19990517/gcc/c
  > onfig/sparc/sol2.h.old  
  > 
  > Ups, wrong argument order...
  > 
  > mistel% diff -u egcs-19990517/gcc/config/sparc/sol2.h.old egcs-19990517/gcc
  > /config/sparc/sol2.h 
  > --- egcs-19990517/gcc/config/sparc/sol2.h.old   Fri Jun 18 17:42:44 1999
  > +++ egcs-19990517/gcc/config/sparc/sol2.h       Fri Jun 18 17:43:07 1999
  > @@ -82,9 +82,9 @@
  >  /* Use .uahalf/.uaword so packed structure members don't generate
  >     assembler errors when using the native assembler.  */
  >  #undef ASM_SHORT
  > -#define ASM_SHORT ".uahalf"
  > +#define ASM_SHORT ".half"
  >  #undef ASM_LONG
  > -#define ASM_LONG ".uaword"
  > +#define ASM_LONG ".word"
All this patch is trade one set of bugs for another set of bugs.

What we really need to do is use autoconf to detect proper support for the
.ua* assembler directives.

jeff

Re: solaris, collect2 and ld (patch)

[Jeffrey A Law]

  In message < 82iu8k2imw.fsf@jms.idonex.se >you write:
  > > All this patch is trade one set of bugs for another set of bugs.
  > 
  > Well - does packed structures work, anyway? What does the assembler do
  > when accessing unaligned words? (I don't know - I've never used packed
  > structures.)
Yes, packed structures are supposed to work.  If they do not, then that is
a bug.

  > Well - I guess the Correct solution would be to use ua* stuff only
  > when needed (in packed structure members). How is this solved on other
  > processors that doesn't support unaligned memory accesses? 
No, the solution is to not use them when the assembler does not support
them.  The only reason those pseudo-ops exist is because the braindamaged
assembler from Sun chokes when *creating* unaligned data.  It has nothing
to do with runtime access -- the compiler will arrange to use memory accesses
that do not fault (falling back to byte mode access if that is necessary).

jeff


  > 
  > /Mirar
  > 
  > 
  > 

Re: solaris, collect2 and ld (patch)

[Mirar]

>   > Well - does packed structures work, anyway? What does the assembler do
>   > when accessing unaligned words? (I don't know - I've never used packed
>   > structures.)

> Yes, packed structures are supposed to work.  If they do not, then that is
> a bug.

Well, I figure out how to create them, and they work (if using unaligned).

>   > Well - I guess the Correct solution would be to use ua* stuff only
>   > when needed (in packed structure members). How is this solved on other
>   > processors that doesn't support unaligned memory accesses? 

> No, the solution is to not use them when the assembler does not support
> them.  The only reason those pseudo-ops exist is because the braindamaged
> assembler from Sun chokes when *creating* unaligned data.  It has nothing
> to do with runtime access -- the compiler will arrange to use memory accesses
> that do not fault (falling back to byte mode access if that is necessary).

Well, it isn't the assembler that doesn't support them - it's the
ld.so. The assembler supports them too good, that is the problem. They
are transferred through and the relocation data chunks get "unaligned"
flags, too - which isn't supported by the ld.so (since solaris 2.2).

I don't know if it's as or ld.so that has been changed, but the
problem remains.

That's why I think ua* well can be used when dealing with unaligned
stuff, but avoided when it's not unaligned.

/Mirar