http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50581
Steven Fuerst <svfuerst at gmail dot com> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |svfuerst at gmail dot com
--- Comment #7 from Steven Fuerst <svfuerst at gmail dot com> 2011-10-02
19:47:46 UTC ---
> Actually, I'm not sure why va_list is defined as an array in some of the
architectures.
The underlying issue is that the ABI on some architectures requires it. They
may use "register windows" instead of stacks to pass parameters to functions.
i.e. r1-r5 might refer to the registers in the function that called you.
r6-r10 might refer to the registers in the function that called the function
that called you. etc. The act of calling a function then changes the values a
set of registers refers to. So when you call a function, what it sees as
r6-r10 are the values that you see in r1-r5.
With this type of ABI, you access your parameters from i.e. r1-r5. Any
functions that you call cannot do this though... as the registers are renamed.
So va_list cannot be a pointer type as there is nothing to point to.
So how do you implement va_args for these arches then? The trick is to use an
array. C requires that an array decays to a pointer when it is passed as an
argument. This means that the array must be stored on the stack, and not in
the renamable registers. This allows the code to get a handle on how many
stack (and register) frames up the calling sequence it needs to go to find the
parameters. The array can then store information about i.e. how many integer
and floating point registers have been read from the variable argument list.
