Linux on VAX - Dead ?

[Maciej W. Rozycki]

On Sun, 15 Jan 2023, Maciej W. Rozycki wrote:

>  Coincidentally I have literally just ported `gdbserver' to VAX/NetBSD (in 
> the course of handling GDB PR tdep/29804) and it has revealed what G++ 
> testing has also shown, and specifically that GCC has broken exception 
> handling with the VAX target, e.g.:
> 
> terminate called after throwing an instance of 'gdb_exception_quit'
> terminate called recursively
> Abort (core dumped)
> 
> It seems a preexisting problem given that I have observed similar traps 
> with native VAX/NetBSD GDB 8.3 shipped with the distribution.  I think 
> this has to be sorted before VAX/NetBSD switches to a newer version of GCC 
> even if technically it's not a regression.
> 
>  I'll see what I can do to get this sorted with GCC 13 (and possibly 
> backported), but note that Stage 3 ends literally today, so it may not be 
> possible after all.

 For the record, it is a serious problem.  The generic implementation of 
the DWARF frame unwinder seems completely unfit for the VAX frame format.  
I spent at least two days trying to make it fit and I was unable to do 
that with the hooks available; there are simply too many assumptions there 
that are not right for VAX frames.

 There are comments like:

  /* Operand 1 is the number of bytes to be popped by DW_CFA_GNU_args_size
     during EH unwinding.  We must include the argument count pushed by
     the calls instruction.  */

in the VAX backend, which are completely bogus as DW_CFA_GNU_args_size 
tags aren't built from information provided by code they refer to in the 
first place.  The code along with the comments has been there since 2002, 
which makes me think exception handling has never worked with VAX/NetBSD, 
not at least with the ELF format.  Not even relocations produced for FDE 
records are right (that at least is a simple fix, but it shows the state 
of affairs here).

 Since it seems to me like a larger project I'll try to fit it into GCC 14 
timeframe.  Given the fixed format and the completeness of information 
stored in VAX frames themselves perhaps it doesn't make sense to use the 
DWARF unwinder (a VAX-specific version) in the first place and an entirely 
VAX-specific frame unwinder will be a better approach.  An advantage would 
be the possibility to throw exceptions across functions that have been 
built with no unwind tables and maybe even to catch them.

 Given that old binary code does not work anyway such a change shouldn't 
cause an ABI compatibility concern.

  Maciej