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
68040?).

  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

-- 
Michael L. Hitch			INTERNET:  osymh@montana.edu
Computer Consultant			BITNET:  OSYMH@MTSUNIX1.BITNET
Office of Systems and Computing Services
Montana State University	Bozeman, MT	USA

------------------------------------------------------------------------------