[m-dev.] cvs diff: SPARC position-indepenent code
fjh at cs.mu.oz.au
Sun Feb 9 16:57:05 AEDT 1997
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
> Also, we should document that -fpic is limited - from the gcc
> "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 220.127.116.11 | -- the last words of T. S. Garp.
More information about the developers