[Oberon] A2 Repository
schierlm at gmx.de
Thu Jun 20 23:25:14 CEST 2019
Am 05.06.2019 um 22:56 schrieb Michael Schierl:
> Yes, I tried that one, and I also tried adding --platform=Bios32 (and
> --extension=.Gof), but the resulting images (I used the Virtualbox ones)
> do not boot - last line is "OBERON loading" and then the screen remains
> Now I also tried again building 2353b6eb64256dfa1373126ba209bb417401ff81
> (r8817) but the resulting images (after I increase the partition size
> since extracting the .ZIP files always trapped for me) act the same.
Same result when trying r8022. Also serial trace does not output anything.
I then started bisecting from the "last known good build" r6498 and
"first known bad build" r8022, and the latest build (of the ones chosen
by git bisect) that I got to compile and boot was r7366.
I used WinAOS 32-bit for building (as I could not get any other version
to start on this old revision) and had to remove the second reference to
Oberon.Display.Mod in Release.Tool.
When trying the same on the next revision (r7367,
the system reboots immediately, and assuming that I can trust the
VirtualBox log, it is due to a triple fault. Behaviour is the same up to
at least r7375.
When taking r7367 and using Heaps.Mod from r7366 (plus adding an empty
CheckAssignment* implementation), the system boots again. So, the triple
fault is likely caused by a change in Heaps.Mod.
Observations about some other revisions I tried during bisecting:
r7387 compiles (after removing second Oberon.Display.Mod again) but
immediately freezes when booting (no triple fault). When using Heaps.Mod
from r7366 (plus adding NgcSweeps variable), the system boots again.
For r7409/r7412/r7461 there were many compile time errors I was not
quickly able to fix.
For r7641/r7748 (yay, somebody removed the double Oberon.Display.Mod!),
compilation failed due to Trace.Int not able to link against runtime
intrinsics for doing DIV/MOD on HUGEINT, so I patched it to only output
LONGINT values. Yet no way for me to get it to boot.
So I guess, the next step would be to do another bisecting round to
figure out where between r7387 and r7409 the compile time errors got
introduced (and how to best fix/workaround them).
Another route would be to have a closer look at the Heaps.Mod changes in
r7367 and try to partially revert them to find out which change exactly
caused the break. This might bring greater insights but be not the
fastest way of getting to a recent build that works (as the error might
have been fixed in a future version already, which I could not test due
to the compile time errors).
Of course, if anyone has a better idea, I'm all ears.
More information about the Oberon