Subject: Re: What changed in fpsp.o?
To: Olaf Seibert <email@example.com>
From: Michael L. Hitch <firstname.lastname@example.org>
Date: 06/07/1994 09:40:04
On Jun 7, 10:57am, Olaf Seibert wrote:
> The update listing reports:
> > Modified Files:
> > fpsp.U
> > Log Message:
> > Fresh compilation, with a few bugs fixed.
> but now the magic number has changed from "NetBSD/m68k object file not
> stripped" to "NetBSD/m68k4k object file not stripped" and ld refuses to
> touch it (muttering about it not being a native object file).
Hmm, it linked fine for me. I'll have to check the MID code on my file.
> What is a "m68k4k"? A typo of "m68k40" (68040) or something like that?
I think m68k4k is an m68k arch with 4K pages, but that should only be
in reference to an executable binary (the binaries can have a 4k page size
or an 8k page size - the Amiga is using 8k pages).
> I edited the magic number to conform to that of all of the other object
> files I had, and then linking proceeded fine (well, with the exception
> of those retina files included by config.new). The resulting kernel
> however ran some binaries, and not others. The changed mmap call is not
> what seems to be the problem (my binaries are too old for that and use
> what now probably is called ommap), but perhaps floating point is.
> Some that worked: init, ls, bash, cat, mount, ldd.
> Some that didn't: more, vi, od. (These didn't produce any output at all
> and just terminated)
> Trying ktrace and kdump to find which system call (if any) would be
> the problem didn't help; perhaps the log file format changed, in any case
> kdump complained about the log file.
> The relevant kernel source was supped 6 june; the binaries are very old
> (shared lib rev 4)
I am assuming you are running on a 68040. It's a problem with changes to
the cachectl() routine not being reflected in ld.so (anyone remember way back
to when shared libraries were first introduced - they didn't work on the
A quick fix is to change amiga/sys_machdep.c to not compile the new
cachectl stuff. There's an #ifdef M68040 in the cachectl routine. I just
changed it to #ifdef notyet /*M68040*/ to get things working.
The correct fix is to fix the cachectl call in ld.so
(gnu/usr.bin/ld/m68k/mdprologue.S) to set up the arguments correctly.
[When I first added the cachectl calls, the cachectl routine in sys_machdep
didn't use the address/length arguments, and there wasn't any documentation
on the call, so I didn't bother setting those up.]
Michael L. Hitch INTERNET: email@example.com
Computer Consultant BITNET: OSYMH@MTSUNIX1.BITNET
Office of Systems and Computing Services
Montana State University Bozeman, MT USA