[CLN-list] Build problems on Solaris 8

[Bruno Haible]

Hello Richy,

> I had the opportunity to do some testing on a SPARC machine and it turns 
> out that CLN is indeed broken. However, if one configures with 
> CPPFLAGS="-DNO_ASM" it works fine and passes all checks.
> 
> One thing that is sure broken are the functions in cl_low.h that use the 
> _get_g1 macro. It appears like %g1 contains garbage. Googling around I 
> was unable to find any useful information. Is there some SPARC expert 
> who can provide insight into what's going on?

I'm not a SPARC expert; my info is mostly taken from the GCC machine
description for SPARC:
The SPARC registers %g0 ... %g7 are called "global" registers because they
retain their value upon entry into and exit from a function. %g0 is always 0.

gcc-2.7.2.3 had this info:

  On pre-v9 systems                              On v9 systems
  -----------------                              -------------
  %g1 used as a temporary by gcc.                likewise
  %g2..%g4 reserved for the program.             likewise
  %g5 reserved for the operating system.         used as a temporary by gcc.
  %g6,%g7 reserved for the operating system.(*)  likewise

gcc-4.2.2 also notes that on v9 systems:
  - %g1 and %g5 are not only used as temporaries by gcc but also during
    calls to external functions via the PLT (the usual case for external
    symbols in a shared library).
  - %g4 is now also used as a temporary by gcc.

So if there is trouble with using %g1, it can be due to one of these:
  a) use of %g1 as a scratch register by gcc (either due to the use of
     newer gcc versions, or because some CLN types are now 64-bit that
     were 32-bit previously),
  b) use of %g1 by the PLT code.

You can distinguish these in two ways:
  - Look at the code generated by gcc (e.g. "make cl_DS_mul.s"). Does it
    contain use of %g1 as a scratch register between the return from mulu32_
    and the fetching of the high part of the multiplication result? And in
    similar locations. If yes, then (a) is the culprit.
  - Compile cln with  CFLAGS="-fPIC -O2" --disable-shared --enable-static.
    As I understand it, the PLT will then not contain symbols like mulu32_
    any more but the code generated is otherwise the same as in the shared
    library case. If the problems persist, it was (a), otherwise (b).

Possible fixes: Replace the use of %g1 with %g2 or %g3 (look at the assembly
code produced by gcc to guess which of the two is likely to work better).

Bruno


(*) As I understand it, one of these two is used as the "current thread"
    pointer. On Linux, it is %g7, see glibc-2.7/nptl/sysdeps/sparc/tls.h :
      register struct pthread *__thread_self __asm__("%g7");