[m-dev.] cvs diff: SPARC position-indepenent code

[Fergus Henderson]

Tyson Richard DOWD, you wrote:
> 
> > Add support for generation position-independent code on SPARCs.
> > (Currently we use non-PIC .so files, which means that although
> > they're shared on disk, they're not shared at runtime.)
> > Note that this change is not yet enabled -- the code I've added
> > will only be used if you compile with `-fpic', but the default
> > is still to compile without `-fpic'.
> 
> If this suffers the same PIC/non-PIC compatability problems that
> we encounter under Linux, it should be documented somewhere (eg
> a new README.Sparc or README.Sun).

It doesn't.  The PIC/non-PIC problems are just because on i386
we use `ebx' as a global register variable in the non-PIC code.
On the SPARC, the register pressure is not so intense, so we
can (and do) leave `l7' alone in non-PIC code.  So there are no
PIC/non-PIC compatibility problems on the SPARC.

I have added some more to README.Linux to make it clear that the
problem only applies to x86s: in the last paragraph, I inserted
the remark in parentheses:

	Be careful that you do not mix PIC Mercury code or non-PIC Mercury code,
	otherwise your code will almost certainly crash.  (The reason for this
	is that non-PIC Mercury code uses the `ebx' register in ways that are
	incompatible with its uses as the global offset table pointer register
	in PIC code.  If only the Intel architecture wasn't so register-starved,
	we wouldn't need to use `ebx', and then PIC and non-PIC code could be
	mixed without any problems.)  The static version of the Mercury
	libraries uses non-PIC code, while the shared version uses PIC code.

I have also added some documention on the use of PIC for Solaris
in configure.in.

> Also, we should document that -fpic is limited - from the gcc
> documentation.
> 
> 	"Such code accesses all constant addresses through a global
> 	offset table (GOT). If the GOT size for the linked executable
> 	exceeds a machine-specific maximum size, you get an error
> 	message from the linker indicating that `-fpic' does not work;
> 	in that case, recompile with `-fPIC' instead. (These maximums
> 	are 16k on the m88k, 8k on the Sparc, and 32k on the m68k and
> 	RS/6000. The 386 has no such limit.)"

Well, since we don't document `-fpic' in the first place, I don't think
there's any point in us documenting that it is limited ;-)

It would be a good idea at some stage to document how to create
your own Mercury libraries, including shared libraries.
However, I don't plan to fix that right now (and I don't
consider it essential to fix before the next release).
Any users who are capable of figuring out that they need
to use `-fpic' for shared libraries should be capable enough
to figure out that when they need to use `-fPIC'.

Of course, if anybody feels like adding the documention on how to
create Mercury libraries, volunteers are always appreciated ;-)

-- 
Fergus Henderson <fjh at cs.mu.oz.au>   |  "I have always known that the pursuit
WWW: <http://www.cs.mu.oz.au/~fjh>   |  of excellence is a lethal habit"
PGP: finger fjh at 128.250.37.3         |     -- the last words of T. S. Garp.