Linux on VAX

[Maciej W. Rozycki]

Hi Jan,

> > > The next issue is moving from reload to LRA, but that is not imminent.
> > > I'm sure our assistance would be welcome here, but our port has never
> > > reached the stability required for the GCC test suite to produce stable
> > > results, which in turn is required for port verification.
> >
> > I volunteered some years ago and I volunteer again: Having ported the
> > GNU compiler toolchain to VMS/AXP, I believe to have some experience
> > maintaining this code ;-)
> >
> > Can you point me to a (github?) repo where this code is hosted ?
> 
> Hello Klaus,
> 
> I managed to locate the old CVS system with the files, but I assume
> that some work on the code has been done afterwards.
> http://linux-vax.cvs.sourceforge.net/viewvc/linux-vax/

 My understanding is Klaus referred to GCC rather than the Linux kernel.  

 The problem I came across WRT stability was probably neither as I had 
issues with many programs exhausting the stack space despite a decent 
amount (in VAX terms) of RAM installed in my system (128MiB).  For example 
`bash' mostly worked (full-fledged, linked with `ncurses', etc.) as did 
`init' (SysVinit), however e.g. `ldconfig' invoked to update `ld.so.cache' 
crashed as did other programs.

 IIRC I got `gdbserver' working, which would allow remote debugging 
(always good with an unstable system!), but cross-GDB (run on an x86/Linux 
host) had issues with interpreting DWARF in VAX/ELF binaries, so I didn't 
get there yet.  Native VAX/Linux GDB outright crashed as did native GCC.

 I don't recall the kernel crashing though, so fatal breakage was all 
confined to the userland.  I can't completely preclude a GCC code 
generation bug having been the cause though.  It was fully reproducible in 
the same scenarios, so I don't think a hardware issue was the cause.

> Maybe Maciej could point you to a newer archive?

 I have an old `kernel.org' VAX repo GIT checkout, as at 2.6.23-rc4, from 
before the break-in caused most repos to go, I have forward-ported the 
original VAX stuff up to 2.6.27-rc8 (though I mostly used 2.6.18), and 
used a huge pile of patches on top of that.  Some was platform-specific, 
such as VAXstation 4000/90 support or TURBOchannel support for same and 
for the VAXstation 4000/60.  And some was generic, such as an interrupt 
handling rewrite, including mapping the hardware SPL model to truly 
Linux-style mask-and-ack management, modelled after the Alpha port 
(otherwise horrible interrupt latencies resulted in lost timer ticks and 
prevented NTP timekeeping from working and caused other problems).

 I could publish this stuff at `ftp.linux-mips.org' I suppose, although I 
do think if we were to go anywhere on the kernel side we'd have to start 
by taking the current version of Linux rather than ancient 2.6 and redo 
the port on top of that.

 As to the userland part, including a port of glibc 2.4 (the final one I 
could make LinuxThreads work with) in particular, it's all still there at:

<ftp://ftp.linux-mips.org/pub/linux/mips/people/macro/>

with source stuff in SRPMS/ (mixed with MIPS and some Alpha stuff), and 
then VAX host binaries in RPMS/vax/, VAX target toolchain pieces in 
RPMS/i386/ (vax-linux-* files) and VAX target libraries in RPMS/noarch/ 
(again vax-linux-* files).  I still have the old build environment set up, 
with RPM having tweaks applied (and also published at the above site) such 
as to work with cross-compilation, e.g. library dependencies are correctly 
determined for non-native ELF binaries.

 I still have some VAX hardware that works (my 4000/90, mysteriously, went 
braindead as in "all diagnostic LEDs steady lit after power-up" and then 
became alive again after a year or so of being braindead, for a reason I 
still haven't figured out and probably never will), so I could try pushing 
this effort forward again if motivated enough.

  Maciej