SMART@UUNET.UU.NET (Robert Smart) (11/25/88)
I wanted to enhance GNU CC to understand the C$INCLUDE logical
that the VMS C compiler knows about. Actually I wanted it to
work better than VMS C, so that it would understand things
like "../h/x.h".
I had recently received 1.30 and installed it on our Sun, so I
thought: silly to enhance 1.22 on VMS, I'll just get 1.30 going
under VMS then attack that.
First problem was unknown symbols GCC_INCLUDE_DIR and GPLUSPLUS_INCLUDE_DIR.
I just gave them an appropriate looking definition under ifdef VMS.
It seemed that they were only used for calculating a length of the
initial part of a file name.
The second problem was with the new bison. I know now that I should
have just copied the unix *.tab.c to *_TAB.C on VMS, but I didn't
know that then. So I got the new bison running, but it mysteriously
put a byte of all ones in the middle of the file. I had to make
the following change to output.c:
************
File C:[SMART.GNU.BISON]OUTPUT.C;2
1281 if( c!=EOF) putc(c, ftable);
1282 c = getc(fpars);
******
File C:[SMART.GNU.BISON]OUTPUT.C;1
1281 putc(c, ftable);
1282 c = getc(fpars);
************
I wonder why this isn't a problem in unix?
I might say that GCC gave an unhelpful error message for the bad
character. I tried compiling with VMS C and got the obvious error
message: illegal character on line etc.
There were various minor problems with the make*.com files. Source
files had changed their names, or new ones added.
I now had problems assembling the output from c-parse_tab.c. I
decided I'd better create the new assembler. GCC 1.22 had an immediate
problem in that there was no varargs.h -- I put the one from the
1.30 distribution in the include directory. The make-gas.com file
also required error=as_fatal added to the /DEFINEs for xrealloc,
xmalloc, hash and vms.
But that didn't make any difference. So I looked at the .s file
and it seemed to be corrupted. So I decided that gcc 1.22 couldn't
handle it. So I went over to the Sun to make a 1.30 cross-compiler for
VMS. Now this isn't easy. There is just one #define VMS which means
both "this will execute under VMS" and "this will produce code for VMS".
So I changed all the #define VMS to #define VMSc wherever it seemed
to mean the former. This worked after I'd grabbed a few .H files
from the old VMS release, and used -I. This produced a .s file which
the VMS gas almost liked. It didn't like:
_yydebug:
.long 0
.comm _yydebug,0
It said that was "illegal attempt to redfine _yydebug". I put the .comm
line before the other 2 and it was happy. This is a bug somewhere in cc1.
Well that now all compiled and linked without error. But the resulting
compiler bombs out compiling a simple program. The next steps look
less trivial than the ones I have taken, and perhaps I should do some
real work :-(. Has anyone else had a go at this? I could try
using my 1.30 cross compiler for everything in case 1.22 is producing
bad code. Or make a debug version of the compiler and try to
understand what is going on.
Helppppppppppppp!
Bob Smart, CSIRO Division of Information Technology, Australia
<smart@ditmelb.oz.au> or <smart%ditmelb.oz.au@uunet.uu.net>
P.S. The GCC 1.30 distribution is also missing lots of the bits necessary
to make a complete VMS distribution: VMS style .H files; the source
of GCC.EXE; the source of extra library routines in GCCLIB.OLB. I am
assuming these are unchanged from 1.22.ee-sno%wasatch@CS.UTAH.EDU (Niel Orcutt) (11/28/88)
About Dr. Smart's problems with GCC 1.30 on VMS: I tried pretty much the same tricks as he did. I even went so far as to create a cross compiler on a large UNIX host and produce .s files, which I then assembled and linked on the VMS host. I used the c-parse_tab.c that came with the distribution. I had to upload the VMS include files to the UNIX host and use -I to point the cross compiler to them. I made a set of .s files with -O on and another set with -O off (also, remember to put -DPCC_ALIGNMENT in the command line). The resultant executable behaved just like the executable that I had previously created using GCC 1.22; it produced a register dump indicating that some function had tried to read through the NULL pointer. When creating an executable using GCC 1.22, I had to create c-parse_tab.s and then edit it to change an instruction of the form movab _<garbage>,r2 This line appeared somewhere between line 10000 and 11000 in c-parse_tab.s. The <garbage> varied from compilation to compilation. I replaced <garbage> with "_hash_table.0", as I recall. This produced a linkable GCC with the warning that Dr. Smart mentioned. When I used the 1.30 cross compiler, this problem disappeared, but the warning remained. So, I gave up the effort also. Does anyone have working GCC 1.3x sources or binaries for VMS?