[pups] Swap device in V6?
johnh at psych.usyd.edu.au
Wed Feb 28 13:24:22 AEST 2001
> The good news is, this fixed my ps problem - ps now works. The bad news
> is that cc still fails with the following error:
> fFatal error in /lib/c0
> The lowercase f appears, followed shortly by the rest of the line. I've
> tried the -c option to suppress linking, and still get this error. I
> don't get this error on the Supnik emulator.
'/lib/c0' is the first pass of the C compiler, after the preprocessor
has be run (the order is cc, c0, c1, c2 for the optimiser, and then 'as'
to produce the object file). I dimly recall that the various passes forked
by 'cc' didn't bother to catch signals, so any error just gives the
"Fatal error in ..." message. The '-c' would have no effect this early.
You could try the '-f' option, that uses a different compiler (with FP
Assuming that you don't have a corrupted binary, or faulty processor/memory,
then is one obscure possibility. While a user program will not see any
difference between a 11/34 and 11/40 (except for floating point instructions),
the behaviour after a memory management fault IS different. The non ID space
processors (11/23/34/35/40/60) don't have a register to record the changes
in the general cpu registers after a fault, and it has to be calculated in
software. The 34 and 40 leave the registers in different states after a fault.
The classic example is "cmp -(sp), -(sp)" to extend the stack. This may generate
a fault because the stack needs to grow dynamically. The kernel extends the
stack (where automatic variables are allocated), and then attempts to
reexecute the instruction. In the case of a 34 using a standard m40.s,
it sometimes gets it wrong, and is very program and data dependent.
Does this ring any bells with people having ported unix to 11/34's?
Received: (from major at localhost)
by minnie.cs.adfa.edu.au (8.9.3/8.9.3) id OAA71920
for pups-liszt; Wed, 28 Feb 2001 14:58:47 +1100 (EST)
(envelope-from owner-pups at minnie.cs.adfa.edu.au)
More information about the TUHS