maslen@neon.stanford.edu (Thomas Maslen) (08/31/89)
[ Posted to comp.unix.ultrix and comp.sys.mips, followup-to
comp.sys.mips; hope that's appropriate. My apologies if this has
been around the net previously, but I haven't seen it in the traffic
since 15-Aug. ]
I'm trying to port a Prolog implementation (SICSTUS 0.6, including the
foreign function interface) which wants to use incremental loading
("ld -A") to do clever things at runtime; I'm not having much fun.
Has anyone Out There successfully used the -A flag?
If it matters, I'm working on one of the server boxes in the same
family as the DECStation 3100, running Ultrix 3.1 (at least, I think
that's what the login gibberish is trying to say). It is my
impression, however, that my problems stem from MIPS-derived software
rather than from anything weird that DEC did -- please tell me if I'm
wrong.
The main thing that makes life difficult is GP-addressed variables
(small data and small bss). I understand why incremental loading
demands that all the newly loaded modules be compiled with -G 0, but
it's still a pain to deal with. For modules under my control, I can
simply grit my teeth and add -G 0 to the Makefile, but when those
modules refer to something in a library (e.g. libc.a) which isn't
already linked into the program, and that something uses GP
addressing, it's a little difficult for me to do much about it. So:
(1) Is there a way to deal with this that I don't know about?
Maybe a program which, somewhat in the manner of pixie, mungs
.o files to remove any GP-relative addressing (how feasible is
it to use $at for this sort of thing?)
(2) Failing that, how have other people dealt with porting systems
that want to load foreign functions at runtime? I assume
that this should arise in some of the LISP and Prolog systems
that were on John Mashey's list of third-party software for
MIPS boxes (true?).
(3) The good folks at MIPS normally have pretty convincing numbers
to back their decisions. Question: how much slower would
things be if the system-wide default was -G 0 rather than -G 8?
(Yes, I realize this is as ill-formed a question as "so, how
many MIPS does it do?"). Wouldn't -G 0 be a better default,
with -G 8 left for the speed freaks?
The 26-bit addresses in jumps are also a bit of a nuisance, but it
looks as though one can get around this by building the original
(non-incremental) executable with -N (OMAGIC) or perhaps with clever
choice of -T and -D values.
If anybody cares, the rest of SICSTUS 0.6 seems to work pretty
happily, although we haven't tested it a whole lot. The save/restore
code needed some tweaking to find the start of the (writable) data
segment, but that was about all.
Thanks for any light you can shed,
Thomas Maslen maslen@polya.stanford.eduzs01+@andrew.cmu.edu (Zalman Stern) (08/31/89)
I've ported the Andrew class system dynamic loader to the pmax. At this point, I think it works, but its been a long uphill battle. Lots of small problems here and there... Incidentally, our code doesn't use ld -A since we load and relocate the module ourselves. As to the 28 bit jump address problem I added the following as a switch to cc: "-Wl,-D,1000000". I think you can add it as "-D 1000000" to ld instead if you like. This must be done when linking the base executable that things are going to get loaded into, not the dynamically loaded modules. This effectively gives one 128 megs of text address space and 128 megs of data address space. As for -G 0'ing things, we were fortunate enough to have sources for all the libraries we needed. I suggest you hassle DEC about shipping -G 0 libraries on their MIPS systems. There should be a /usr/lib_G0 directory which contains all the libraries in /usr/lib compiled with -G 0. All in all, if you look this as being similar to large vs. small model libraries on the 8086, it starts to make sense. (Before I get flamed about this, I've already wasted a lot of time trying to get -G 0 and -G 8 code to work together. If you reference a variable < 8 bytes in -G 8 code but that variable is defined in -G 0 code, the link blows up.) Sincerely, Zalman Stern Internet: zs01+@andrew.cmu.edu Usenet: I'm soooo confused... Information Technology Center, Carnegie Mellon, Pittsburgh, PA 15213-3890