>>>>> "JS" == Jonathan Stone <jonathan@DSG.Stanford.EDU> writes:

JS> I suspect there's likely to be a conflict between whatever other
JS> NetBSD ports do, and what other mips gcc targets do: you just
JS> can't win....  Should I fix gcc to default to -fPIC, or change the
JS> -fpic to DTRT for pmax shared libs?

Actually, this may not be necessary.  After some examination, gcc is
defaulting to calling cc1 with -mabicalls, which seems to generate at
least the .abicalls pseudo-op.  The problem comes when the libc stuff
runs afoul the .S.o rule in bsd.lib.mk, which runs the cc frontend and
cpp over an assembler source file.  This ends up not calling the
assembler with -KPIC, with resultant lossage.

I see several possible fixes, some more tasteful than others:

1. Explicitly add .abicalls pseudo-ops to all .S files that end up
being parts of static libraries.  Since everything's going to be PIC
anyway, this seems like a logical solution.  Strangely enough, most of
the .S files already have .abicalls pseudo-ops in them, except that
they're surrounded with #ifdef ABICALLS, which isn't really getting
defined anywhere.  Is there a good reason to conditionalize this,
especially since everything is winding up as PIC anyway?

2. Compile .S files with -fPIC.  This seems unnecessarily ugly and
adds hair to bsd.lib.mk, etc.

3. Default the compiler to -fPIC, which implies -KPIC to the
assembler.  This also seems unnecessary due to default -mabicalls, but
would be necessary for assembly files.

4. Default the assembler to -KPIC.

I don't really have enough background to grasp all the implications of
these options.  Someone with more compiler clue than me should chime
in.  In particular, I'm unclear on whether -mabicalls and -fPIC have
different results.  Does -mabicalls wind up generating code that calls
through a GOT anyway?  If so, is -fPIC thus redundant?

---Tom