GCC for VMS Alpha

[Simon Clubley]

As a little diversion this weekend from another project, I decided to
look at the current state of the VMS code in binutils 2.27 and gcc 6.3.0.

The short version is that it's pretty much unchanged from when I last
looked at this a couple of years ago. An example C program worked ok
on VMS Alpha 8.4, and Fortran, C++ and Ada all still fail.

Before trying to press-gang me into working further on this, I should
point out that my diversion is now over and I am going back to working
on my other projects (although I might look closer at the binutils
problem below in the future just out of personal interest).

More details below and background information for those unfamiliar with
the situation.

Background:

AdaCore is an Ada compiler company whose product is based around the
GNU toolchain. However, they maintain their own fork of the GNU
binutils/gcc/etc toolchain but occasionally push changes from this
toolchain back into the FSF versions.

[AdaCore's VMS changes to the GNU toolchain source code are not
available to non-customers because AdaCore use the GPL option which
says they only have to supply source code to their customers.]

For VMS, AdaCore also maintain their own C headers which are not the
same as the DEC C headers and this shows up while building the gcc
source code which assumes you are using the AdaCore C headers.

These headers are the property of AdaCore which means they are also
not available to non-customers.

As VMS does not have the infrastructure needed to build gcc, especially
when you throw in the Ada front end requirement, the general approach
taken is to:

(1) Build a native Linux toolchain from the same toolchain versions you
want to use on VMS,
(2) Build a cross compiler toolchain on Linux for a VMS target and then
(3) Build a native VMS compiler toolchain from the cross compiler.

The furthest I have ever got in the past is to build the binutils part
of step 3. Further progress was not possible due to the various other
failures (especially when building the C++ front end). However, you can
build VMS executables from the cross compiler in step 2 and then transfer
the binary to your VMS system and run the binary there.

Failure details when building the cross compiler toolchain in step 2 above:

C++ now fails during code generation with the following error:

/tmp/ccyOfaMD.s: Assembler messages:
/tmp/ccyOfaMD.s: Error: no entry symbol for global function '_ZN10__cxxabiv117__array_type_infoD1Ev'
make[4]: *** [array_type_info.lo] Error 1
make[4]: Leaving directory `/work/vms-cc/obj-gcc/alpha-dec-vms/libstdc++-v3/libsupc++'
make[3]: *** [all-recursive] Error 1
make[3]: Leaving directory `/work/vms-cc/obj-gcc/alpha-dec-vms/libstdc++-v3'
make[2]: *** [all] Error 2
make[2]: Leaving directory `/work/vms-cc/obj-gcc/alpha-dec-vms/libstdc++-v3'
make[1]: *** [all-target-libstdc++-v3] Error 2
make[1]: Leaving directory `/work/vms-cc/obj-gcc'
make: *** [all] Error 2

The Fortran cross compiler is successfully built but images built using
it still fail early on during image activation:

$ r sqrt
%SYSTEM-F-ACCVIO, access violation, reason mask=00, virtual address=0000000000000008, PC=0000000000058EF4, PS=0000001B
%TRACE-F-TRACEBACK, symbolic stack dump follows
image module routine line rel PC abs PC
SQRT 0 0000000000058EF4 0000000000058EF4
SQRT 0 0000000000059174 0000000000059174
0 FFFFFFFF80379C44 FFFFFFFF80379C44
%TRACE-I-END, end of TRACE stack dump

The Ada compiler front end still has the same internal compiler error
with a VMS Alpha target that it has always had:

+===========================GNAT BUG DETECTED==============================+
| 6.3.0 (alpha-dec-vms) in plus_constant, at explow.c:87 |
| Error detected around a-direct.adb:769:59 |
| Please submit a bug report; see http://gcc.gnu.org/bugs.html. |
| Use a subject line meaningful to you and us to track the bug. |
| Include the entire contents of this bug box in the report. |
| Include the exact command that you entered. |
| Also include sources listed below. |
+==========================================================================+

[snip]

One possible new regression is in binutils 2.27 itself when building it
as part of the cross compiler.

Building the gcc cross compiler in step 2 above failed when using
binutils 2.27 because the cross compiled ar archiver failed during
execution:

/work/exe-vms-cc/alpha-dec-vms/bin/ar rc libgcc.a $objects
/bin/sh: line 7: 8761 Segmentation fault /work/exe-vms-cc/alpha-dec-vms/bin

Replacing binutils 2.27 with binutils 2.24 worked well enough for
the cross compiler to be successfully built.

I don't currently understand the reason for the binutils 2.27 failure.
I thought I had identified the issue in the 2.27 source code, but
similar code is present in 2.24 and 2.24 works.

It's possible that either something weird happened while building the
cross-compiled binutils either due to an error on my part or a build
failure or it may be that the logic flow is different at a higher level
in binutils than I have currently identified.

In summary, I don't know if AdaCore have pushed all the needed bits
to the FSF toolchain and I have simply not hit on the magic combination
of DEC C header and gcc patches and ./configure options or if not all
the required bits are present in the FSF code base.

Either way, I'm not going to be spending any more real time on this
so I thought I would just report my findings here for the record.

Simon.

--
Simon Clubley, clubley@remove_me.eisner.decus.org-Earth.UFP
Microsoft: Bringing you 1980s technology to a 21st century world