Using and Porting GNU CC
This section describes the macros which let you control how various types of arguments are passed in registers or how they are arranged in the stack.
FUNCTION_ARG (cum, mode, type, named)
The arguments are cum, which summarizes all the previous
arguments; mode, the machine mode of the argument; type,
the data type of the argument as a tree node or 0 if that is not known
(which happens for C support library functions); and named,
which is 1 for an ordinary argument and 0 for nameless arguments that
correspond to `
...' in the called function's prototype.
The value of the expression should either be a
reg RTX for the
hard register in which to pass the argument, or zero to pass the
argument on the stack.
For machines like the Vax and 68000, where normally all arguments are pushed, zero suffices as a definition.
The usual way to make the ANSI library `
stdarg.h' work on a machine
where some arguments are usually passed in registers, is to cause
nameless arguments to be passed on the stack instead. This is done
FUNCTION_ARG return 0 whenever named is 0.
You may use the macro
MUST_PASS_IN_STACK (mode, type)
in the definition of this macro to determine if this argument is of a
type that must be passed in the stack. If
is not defined and
FUNCTION_ARG returns non-zero for such an
argument, the compiler will abort. If
defined, the argument will be computed in the stack and then loaded into
FUNCTION_INCOMING_ARG (cum, mode, type, named)
For such machines,
FUNCTION_ARG computes the register in which
the caller passes the value, and
be defined in a similar fashion to tell the function being called
where the arguments will arrive.
FUNCTION_INCOMING_ARG is not defined,
serves both purposes.
FUNCTION_ARG_PARTIAL_NREGS (cum, mode, type, named)
On some machines, certain arguments must be passed partially in
registers and partially in memory. On these machines, typically the
first n words of arguments are passed in registers, and the rest
on the stack. If a multi-word argument (a
double or a
structure) crosses that boundary, its first few words must be passed
in registers and the rest must be pushed. This macro tells the
compiler when this occurs, and how many of the words should go in
FUNCTION_ARG for these arguments should return the first
register to be used by the caller for this argument; likewise
FUNCTION_INCOMING_ARG, for the called function.
FUNCTION_ARG_PASS_BY_REFERENCE (cum, mode, type, named)
On machines where
REG_PARM_STACK_SPACE is not defined, a suitable
definition of this macro might be
#define FUNCTION_ARG_PASS_BY_REFERENCE\ (CUM, MODE, TYPE, NAMED) \ MUST_PASS_IN_STACK (MODE, TYPE)
FUNCTION_ARG_CALLEE_COPIES (cum, mode, type, named)
FUNCTION_ARGand other related values. For some target machines, the type
intsuffices and can hold the number of bytes of argument so far.
There is no need to record in
CUMULATIVE_ARGS anything about the
arguments that have been passed on the stack. The compiler has other
variables to keep track of that. For target machines on which all
arguments are passed on the stack, there is no need to store anything in
CUMULATIVE_ARGS; however, the data structure must exist and
should not be empty, so use
INIT_CUMULATIVE_ARGS (cum, fntype, libname)
CUMULATIVE_ARGS. The value of fntype is the tree node for the data type of the function which will receive the args, or 0 if the args are to a compiler support library function.
When processing a call to a compiler support library function,
libname identifies which one. It is a
symbol_ref rtx which
contains the name of the function, as a string. libname is 0 when
an ordinary C function call is being processed. Thus, each time this
macro is called, either libname or fntype is nonzero, but
never both of them at once.
INIT_CUMULATIVE_INCOMING_ARGS (cum, fntype, libname)
INIT_CUMULATIVE_ARGSbut overrides it for the purposes of finding the arguments for the function being compiled. If this macro is undefined,
INIT_CUMULATIVE_ARGSis used instead.
The value passed for libname is always 0, since library routines
with special calling conventions are never compiled with GNU CC. The
argument libname exists for symmetry with
FUNCTION_ARG_ADVANCE (cum, mode, type, named)
This macro need not do anything if the argument in question was passed on the stack. The compiler knows how to track the amount of stack space used for arguments without any special help.
FUNCTION_ARG_PADDING (mode, type)
enum direction: either
upwardto pad above the argument,
downwardto pad below, or
noneto inhibit padding.
The amount of padding is always just enough to reach the next
FUNCTION_ARG_BOUNDARY; this macro does not control
This macro has a default definition which is right for most systems.
For little-endian machines, the default is to pad upward. For
big-endian machines, the default is to pad downward for an argument of
constant size shorter than an
int, and upward otherwise.
FUNCTION_ARG_BOUNDARY (mode, type)
PARM_BOUNDARYis used for all arguments.