public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Randy Dunlap <randy.dunlap@oracle.com>
To: Ingo Molnar <mingo@elte.hu>
Cc: linux-kernel@vger.kernel.org, "H. Peter Anvin" <hpa@zytor.com>,
	Thomas Gleixner <tglx@linutronix.de>
Subject: Re: [tip:x86/asm] x86: document 64-bit and 32-bit function call	convention ABI
Date: Tue, 03 Feb 2009 10:32:51 -0800	[thread overview]
Message-ID: <49888DD3.6000903@oracle.com> (raw)
In-Reply-To: <20090203182256.GA1061@elte.hu>

Ingo Molnar wrote:
> - also clean up the calling.h file a tiny bit
> 
> Signed-off-by: Ingo Molnar <mingo@elte.hu>
> ---
>  arch/x86/include/asm/calling.h |   56 +++++++++++++++++++++++++++++++++++++--
>  1 files changed, 53 insertions(+), 3 deletions(-)
> 
> diff --git a/arch/x86/include/asm/calling.h b/arch/x86/include/asm/calling.h
> index 2bc162e..2d36d42 100644
> --- a/arch/x86/include/asm/calling.h
> +++ b/arch/x86/include/asm/calling.h
> @@ -1,5 +1,55 @@
>  /*
> - * Some macros to handle stack frames in assembly.
> +
> + x86 function call convention, 64-bit:
> + -------------------------------------
> +  arguments           |  callee-saved      | extra caller-saved | return
> + [callee-clobbered]   |                    | [callee-clobbered] |
> + ---------------------------------------------------------------------------
> + rdi rsi rdx rcx r8-9 | rbx rbp [*] r12-15 | r10-11             | rax, rdx [**]
> +
> + ( rsp is obviously invariant across normal function calls. (gcc can 'merge'
> +   functions when it sees tail-call optimization possibilities) rflags is
> +   clobbered. Leftover arguments are passed over the stack frame.)
> +
> + [*]  In the frame-pointers case ebp is fixed to the stack frame.

                                    ebp or rbp ?

> +
> + [**] for struct return values wider than 64 bits the return convention is a
> +      bit more complex: up to 128 bits width we return small structures
> +      straight in rax, rdx. For structures larger than that (3 words or

	What size does "word" mean here?
	and is it rdx:rax (high:low)?  Can it be so written?
	or at least say which of rax, rdx is high (most significant) and
	which is low (least significant).

> +      larger) the caller puts a pointer to an on-stack return struct
> +      [allocated in the caller's stack frame] into the first argument - i.e.
> +      into rdi. All other arguments shift up by one in this case.
> +      Fortunately this case is rare in the kernel.
> +
> +For 32-bit we have the following conventions - kernel is build with

                                                            built

> +-mregparm=3 and -freg-struct-return:
> +
> + x86 function calling convention, 32-bit:
> + ----------------------------------------
> +  arguments         | callee-saved        | extra caller-saved | return
> + [callee-clobbered] |                     | [callee-clobbered] |
> + -------------------------------------------------------------------------
> + eax edx ecx        | ebx edi esi ebp [*] | <none>             | eax, edx [**]
> +
> + ( here too esp is obviously invariant across normal function calls. eflags
> +   is clobbered. Leftover arguments are passed over the stack frame. )
> +
> + [*]  In the frame-pointers case ebp is fixed to the stack frame.
> +
> + [**] We build with -freg-struct-return, which on 32-bit means similar
> +      semantics as on 64-bit: edx can be used for a second return value
> +      (i.e. covering integer and structure sizes up to 64 bits) - after that
> +      it gets more complex and more expensive: 3-word or larger struct returns
> +      get done in the caller's frame and the pointer to the return struct goes
> +      into regparm0, i.e. eax - the other arguments shift up and the
> +      function's register parameters degenerate to regparm=2 in essence.
> +

	Same high:low comments here.

> +*/
> +
> +
> +/*
> + * 64-bit system call stack frame layout defines and helpers,
> + * for assembly code:
>   */
>  
>  #define R15		  0
> @@ -9,7 +59,7 @@
>  #define RBP		 32
>  #define RBX		 40
>  
> -/* arguments: interrupts/non tracing syscalls only save upto here*/
> +/* arguments: interrupts/non tracing syscalls only save upto here: */

                                                           up to

>  #define R11		 48
>  #define R10		 56
>  #define R9		 64

Thanks,
-- 
~Randy

  reply	other threads:[~2009-02-03 18:33 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-02-03 18:22 [tip:x86/asm] x86: document 64-bit and 32-bit function call convention ABI Ingo Molnar
2009-02-03 18:32 ` Randy Dunlap [this message]
2009-02-03 18:48   ` Ingo Molnar

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=49888DD3.6000903@oracle.com \
    --to=randy.dunlap@oracle.com \
    --cc=hpa@zytor.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mingo@elte.hu \
    --cc=tglx@linutronix.de \
    /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