Re: FWIW: VAX fix backport and gcc built on 4.3BSD first time ever!

[msokolov at ivan dot Harhan dot ORG (Michael Sokolov)]

Marc Espie <espie@quatramaran.ens.fr> wrote:

> The gcc used in OpenBSD does have additions to vax.md for precisely that
> problem. Namely, it defines call_pop and call_value_pop (I think... I'm
> not too familiar with that).
>
> This might not be the cleanest solution, but I can vouch that 
> vax-unknown-openbsd28 is a reality.

Hmm, vax.md is definitely the wrong place to fix this. vax.md is correct.
Lesser, more primitive architectures have call and return instructions that
know nothing about high-level language procedure call conventions. These
architectures define call and call_value patterns which do the call after the
arguments have been pushed on the stack and after which they remain there to be
popped by someone else. The divine VAX architecture, OTOH, has function
argument handling instrinsically built into it. By the VAX Architecture
Reference Manual a procedure is to be called with an argument list that has the
number of arguments as its first longword, and if it's on the stack (CALLS is
used instead of CALLG), it is automatically popped. Therefore it is wrong for
VAX to have call and call_value patterns like the lesser architectures do, and
instead it has call_pop and call_value_pop patterns that intrinsically include
the popping of arguments on return.

VAX was among the ports of the very first original gcc, and gcc has
accommodated this from the beginning. A port doesn't have to have call and
call_value patterns, and can have call_pop and call_value_pop instead. It's
just that somewhere along the way calls.c got broken, and John David Anglin's
patch is the correct fix for it. In fact, this is not even VAX-specific.
calls.c simply had a bug in it that made it violate one of gcc's internal rules
as to what patterns a port must define. It broke every port that chose to
define call_pop and call_value_pop, but not call and call_value.

As for OpenBSD, if as you say you hack vax.md to work around this bug in
calls.c, I guess what you are doing is defining call and call_value patterns
that emulate the behavior of lesser architectures on the VAX. I guess you emit
a calls $0, right? If so, please be advised that this violates the VAX
Architecture Reference Manual. While in ANSI/ISO C a function can't determine
how many arguments it was called with, on a VAX it can. 4.3BSD, for example,
being a true VAX OS, makes use of this feature in a few places, as any VARM-
compliant software can legitimately do. Calling functions with calls $0 tells
them that they have no arguments, and thus breaks VARM-compliant software.

> I realize this is probably not the Right Thing to do under those circumstances.
> But if we all sit on our collective bottoms and wait for the Right Guy to
> come in and do the Right Thing for vax, we may have to wait until gcc 5.0...

No, Dave's patch is the right fix, and has been in the mainline gcc since
August 1999. According to Dave, the current mainline gcc bootstraps and works
correctly on VAX Ultrix. I'm now working on getting it to build on 4.3BSD.

--
Michael Sokolov
Public Service Agent
International Engineering and Science Task Force

1351 VINE AVE APT 27		Phone: +1-714-738-5409
FULLERTON CA 92833-4291 USA	(home office)

E-mail: msokolov@ivan.Harhan.ORG (ARPA TCP/SMTP)