The short of this is that I'd like to set up a cross-compiler to target a
MIPS-based CPU (a simulated CPU, actually, that should more or less be a
MIPS R3000.)  I had hoped that I could use our pkgsrc cross-compilers for
this, without engaging too many neurons.  I ran into some snags, and am
now skeptical that I can use our cross-compilers.

My questions are along the lines of: Can someone verify my problems in
other contexts (or did I just happen to grab pkgsrc on a day when these
two cross compilers were broken)?  Why do the compilers generate this
unresolved symbol?


The long version:

I have an academic project that needs a cross compiler for the MIPS type
of CPU.  (Specifically, a simulated CPU provided by the Berkeley Nachos
project.)  Of course, bringing it up on my home machine is the preferred
thing to do...

Out of laziness, I thought that I'd see if I could get our cross-compilers
to do most/all of the work of cross-compiling code for the simulated
CPU.  (Maybe they can, maybe they can't; I don't know enough about how
object formats vary between UNIX-like systems on the same
CPU.  Apparently, at KU, people have been using a version of GCC targeted
for a DEC Ultrix machine.  I've tried both MIPS NetBSD cross compilers in
our pkgsrc (mipse[bl}-netbsd.)

My problem is that I am getting a core dump in the (mipse[bl]-netbsd-)ld
program, which generates an ld.core file.  (Why not a
mips[bl]-netbsd-ld.core?)

The fatal error is:

$ cd nachos/test        ## assumes most of Nachos has been built already
$ gmake clean && gmake
rm -f halt shell matmult matmult2 matmult4 matmult8 sort exit-prog fork
fork-yield count nice access1 access2 *.o *.coff results swapfile
/usr/pkg/cross/bin/mipseb-netbsd-gcc -fno-builtin -G 0 -g -c -I../userprog
-I../threads -I../lib -gcoff -c halt.c
/usr/bin/cpp -I../userprog -I../threads -I../lib start.s > strt.s
/usr/pkg/cross/bin/mipseb-netbsd-as -G 0 -o start.o strt.s
rm strt.s
/usr/pkg/cross/bin/mipseb-netbsd-ld -T script -N start.o halt.o -o
halt.coff
halt.o: In function `main':
halt.c:17: undefined reference to `_gp_disp'
gmake: *** [halt] Segmentation fault (core dumped)

$ grep gp_disp *
Binary file halt.coff matches
Binary file halt.o matches
Binary file ld.core matches

halt.c is fairly innocent-looking (just a #include, an int main(), and one
executable statment, a call to a Halt() function).  Line 17 is the
open-brace of main() (on a line by itself).


Apparently, Nachos is officially ported to NetBSD by the people at
Berkeley, so I may try using their current version, or at least their
cross compiler.  However, there are four questions in my mind:

 * What is gp_disp for?  I can't find it in the man or info pages.

 * How did it get there?  Is it invoked as a wrapper around object code
   for the debugger, or something?  (I tried removing debugging
   options to see if that would cause the cross compiler to stop
   generating the references, but that didn't help.)

 * Are the mipse[bl] cross compilers just broken?  No linker should
   dump core if it can't resolve a symbol.  (pkgsrc from early October;
   NetBSD 1.5_ALPHA from early August.)  Can others verify whether this
   is a general mipse[bl]-netbsd cross-compiler bug, or if it's just
   something quirky about my environment/use?

   (Yes, I've tried both versions of the cross compiler.  Both
   give the same effect: Unresolved gp_disp, and a core-dump to ld.core.)

 * What are the differences between the two mips cross complers?
   The ``long descriptions'' in DESCR don't help much.  E.g.:

       This cross-compile environment is for NetBSD/mipseb.

   ...which is little more than one would assume from the fact that
   it is in pkgsrc/cross/mipseb-netbsd.


  "I probably don't know what I'm talking about." --rauch@eecs.ukans.edu