hansen@pegasus.ATT.COM (Tony L. Hansen) (07/25/89)
I recently ported a 2.0 cfront to a Mips M1000 machine and thought I'd post
a note to the net about a problem on the Mips system encountered during the
port.
The very pernicious Mips bug affected how cfront communicates to the C
compiler that a function is going to take a variable-length argument list.
Since the mips C compiler uses registers to pass parameters around, the C
compiler needs to have a way of being told that a function is going to be a
variable-length argument list, in which case it will dump all arguments to
the stack when the function is started. Because the mips compiler is not an
ANSI compiler, it does not know about the ",..." convention. So they chose a
kludgey method of looking for the particular variable name of "va_alist", as
is used when <varargs.h> is used, to key on as an indication that the
parameters should be dumped to the stack.
Consequently, this requires a kludge in return to force cfront to tell the C
compiler that the function does varargs. My simple kludge is to output a
final argument within the varargs function definition named "va_alist",
which gives the C compiler all the ammo it needs in order to compile the
function properly. Cfront already knows where it should put the ",..." if it
were outputting ANSI C. Using that knowledge, the following four line
addition within fct::dcl_print() will produce the desired (but undesirable?
:-)) C output:
if (body && Cast==0) {
for (nn=at; nn;) {
nn->print();
if (nn=nn->n_list) puttok(CM); else break;
}
> #ifdef mips /* !!KLUDGE CITY!! */
> if (nargs_known == ELLIPSIS)
> putstring(", va_alist");
> #endif
putch(')');
}
else
putch(')');
This bug had prevented us from recompiling cfront with the non-scratch
version of cfront just built. The only way we had gotten cfront to compile
was with the scratch cfront. Otherwise it compiled, but dumped core
immediately. With the above workaround in cfront, it works just fine.
A much simpler method that the Mips C compiler could have used would have
been to just recognize that any parameter is having its address taken and
decide then that the stack should be dumped. (Chris Macey came up with this
idea.) This would probably have taken care of many other varargs-like usages
with little cost.
Tony Hansen
att!pegasus!hansen, attmail!tony
hansen@pegasus.att.com