In-Reply-To: <199703050550.VAA04783@Pescadero.DSG.Stanford.EDU>
References: <199703050550.VAA04783@Pescadero.DSG.Stanford.EDU>

[crt0.S broken]

>I've noticed that you've committed changes in lib/csu/mips.  Are these
>the sources from which the snapshot crt0.o come?

Effectively, yes, it is.  The crt0.o in the snapshot actually came
from Manuel Bouyer's snapshot; the source I committed has some trivial
differences from Manuel's, but that won't affect anything.

>Forgive a potentially stupid question, but *why* is it necessary to
>have all files compiled as PIC?  Is it that non-PIC .o files won't
>link with a shared libc,

Yes, exactly.  Non-abicall .o files won't work with a shared libc, or
when linked against a libc compiled to use and expect the svr4 ABI
calling sequence.  The linker complains, and the resulting binary coredumps.

> and requiring software authors to use
>non-standard cc flags in order to compile either static or dynamic
>binaries is unreasonable?

More-or-less. It's not unbearably onerous, but being different from
other NetBSD ports was seen as a Bad Thing.  I asked port-pmax, twice,
what users preferred, and the answers I got were all in favour of
making the output of cc -c work with both shared and static files by
default.


>Does non-PIC code use a different function
>calling convention than PIC code?

Yes.  It's not really the PIC ness that's at issue, it's whether or
not function calls are done using SVR4 mips abicall.  That requires
setting $t9 to point to the callee's address (so it look up the $gp
value it should use, based on address, and saving/restoring the $GP
register around calls.

We could change cc to not use -mhalf-pic by default; that might make a
trivial difference to the size of static binaries.  Shared-lib .o
files would need to be explicitly compiled with -fPIC.  I'm open to
suggestions on this point.

>I've noticed that Irix, among other
>things, does something similar.

I beleive IRIX is effectively where the svr4 mips ABI comes from.