public inbox for gcc-bugs@sourceware.org
help / color / mirror / Atom feed
From: "svfuerst at gmail dot com" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug c/50581] stdarg doesn't support array types
Date: Sun, 02 Oct 2011 19:48:00 -0000	[thread overview]
Message-ID: <bug-50581-4-UCc66aYmfD@http.gcc.gnu.org/bugzilla/> (raw)
In-Reply-To: <bug-50581-4@http.gcc.gnu.org/bugzilla/>

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.


  parent reply	other threads:[~2011-10-02 19:48 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-09-30 15:49 [Bug c/50581] New: " Wolfgang at Solfrank dot net
2011-09-30 20:13 ` [Bug c/50581] " joseph at codesourcery dot com
2011-10-01 11:07 ` Wolfgang at Solfrank dot net
2011-10-01 14:08 ` joseph at codesourcery dot com
2011-10-01 14:43 ` Wolfgang at Solfrank dot net
2011-10-01 18:46 ` joseph at codesourcery dot com
2011-10-02 16:09 ` Wolfgang at Solfrank dot net
2011-10-02 19:48 ` svfuerst at gmail dot com [this message]
2022-01-03  2:38 ` pinskia at gcc dot gnu.org

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=bug-50581-4-UCc66aYmfD@http.gcc.gnu.org/bugzilla/ \
    --to=gcc-bugzilla@gcc.gnu.org \
    --cc=gcc-bugs@gcc.gnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).