Doubt regarding asmlinkage

Pei Lin telent997 at
Thu Sep 8 03:17:22 EDT 2011

2011/9/8 rohan puri <rohan.puri15 at>:
> On Thu, Sep 8, 2011 at 9:50 AM, Mulyadi Santosa <mulyadi.santosa at>
> wrote:
>> Hi :)
>> On Thu, Sep 8, 2011 at 10:40, rohan puri <rohan.puri15 at> wrote:
>> > Hi Mulyadi,
>> >
>> > Thanks for the response. I do agree with the issue concerning the no.of
>> > registers available are less for 32 bit to that of 64 bit.
>> >
>> > But even in this case if parameters are more than the no of register for
>> > 32
>> > bit, then also before executing int 80h interrupt it stores the
>> > parameters
>> > in the register and after that system call dispatcher puts them on the
>> > kernel stack of that process. So, how the case where more than no of
>> > registers are the parameters to the system call is handled.
>> Please don't top post :)
>> Regarding passing the parameters when it is more than number of
>> registers used in x86 32 bit, AFAIK it's using EDX to contain the
>> address of user space memory that contains the data, later it will be
>> copied to kernel stack IIRC.
>> --
>> regards,
>> Mulyadi Santosa
>> Freelance Linux trainer and consultant
>> blog:
>> training:
> Sorry for top posting. :)
> Got it now. Thanks.
> Regards,
> Rohan.
> _______________________________________________
> Kernelnewbies mailing list
> Kernelnewbies at
Kernel newbies website crashed? can not login, only get the snapshot as below.

What is asmlinkage?
The asmlinkage tag is one other thing that we should observe about
this simple function. This is a #define for some gcc magic that tells
the compiler that the function should not expect to find any of its
arguments in registers (a common optimization), but only on the CPU's
stack. Recall our earlier assertion that system_call consumes its
first argument, the system call number, and allows up to four more
arguments that are passed along to the real system call. system_call
achieves this feat simply by leaving its other arguments (which were
passed to it in registers) on the stack. All system calls are marked
with the asmlinkage tag, so they all look to the stack for arguments.
Of course, in sys_ni_syscall's case, this doesn't make any difference,
because sys_ni_syscall doesn't take any arguments, but it's an issue
for most other system calls. And, because you'll be seeing asmlinkage
in front of many other functions, I thought you should know what it
was about.

It is also used to allow calling a function from assembly files.

There also have explicit explanation in the kernel maillist archive.
Date:	Sat, 18 Jun 2005 16:29:01 +0200
To: Roy Lee <roylee17 at>

On Sat, 18 Jun 2005 22:00:39 +0800
Roy Lee <roylee17 at> wrote:

> It says that "To tell a compiler not to use the argument in the
> registers". but the syscall's argument does pass the arguments though
> registers, doesn't it?

yes, user space programs put arguments in registers (ebx, ecx, edx...) but
see what happens later...

1) user space programs do something like this:

mov $ARG1, %ebx
mov $ARG2, %ecx
int $0x80 ------ go to kernel syscall handler --->

---> arch(i386/kernel/entry.S:

        # system call handler stub
        pushl %eax # save orig_eax
                                        # system call tracing in operation
        /* Note, _TIF_SECCOMP is bit number 8, and so it needs testw
and not testb
 */ testw
syscall_trace_entry cmpl $(nr_syscalls), %eax
        jae syscall_badsys
        call *sys_call_table(,%eax,4)
        movl %eax,EAX(%esp) # store the return value

notice just these 2 things:

1) SAVE_ALL ---> it's a MACRO that do this:

#define SAVE_ALL \
        cld; \
        pushl %es; \
        pushl %ds; \
        pushl %eax; \
        pushl %ebp; \
        pushl %edi; \
        pushl %esi; \ ....
        pushl %edx; \ > ARG3 <
        pushl %ecx; \ > ARG2 <
        pushl %ebx; \ > ARG1 <
        movl $(__USER_DS), %edx; \
        movl %edx, %ds; \
        movl %edx, %es;

2) call *sys_call_table(,%eax,4)

this calls the "C" system call function

So, since the arguments are passed on the stack (see SAVE_ALL) the "C"
function MUST take them from the stack.

Best Regards

More information about the Kernelnewbies mailing list