Doubt regarding asmlinkage

[rohan puri]

On Thu, Sep 8, 2011 at 12:47 PM, Pei Lin <telent997 at gmail.com> wrote:

> 2011/9/8 rohan puri <rohan.puri15 at gmail.com>:
> >
> >
> > On Thu, Sep 8, 2011 at 9:50 AM, Mulyadi Santosa <
> mulyadi.santosa at gmail.com>
> > wrote:
> >>
> >> Hi :)
> >>
> >> On Thu, Sep 8, 2011 at 10:40, rohan puri <rohan.puri15 at gmail.com>
> 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: the-hydra.blogspot.com
> >> training: mulyaditraining.blogspot.com
> >
> > Sorry for top posting. :)
> >
> > Got it now. Thanks.
> >
> > Regards,
> > Rohan.
> >
> > _______________________________________________
> > Kernelnewbies mailing list
> > Kernelnewbies at kernelnewbies.org
> > http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
> >
> >
> Kernel newbies website crashed? can not login, only get the snapshot as
> below.
> http://kernelnewbies.org/FAQ/asmlinkage
>
> FAQ/asmlinkage
> 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 gmail.com>
>
>
> On Sat, 18 Jun 2005 22:00:39 +0800
> Roy Lee <roylee17 at gmail.com> 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 $SYSCALLNUMER, %eax
> mov $ARG1, %ebx
> mov $ARG2, %ecx
> ...
> int $0x80 ------ go to kernel syscall handler --->
>
>
>
> ---> arch(i386/kernel/entry.S:
>
>
> ....
>        # system call handler stub
> ENTRY(system_call)
>        pushl %eax # save orig_eax
>        SAVE_ALL
>        GET_THREAD_INFO(%ebp)
>                                        # system call tracing in operation
>        /* Note, _TIF_SECCOMP is bit number 8, and so it needs testw
> and not testb
>  */ testw
> $(_TIF_SYSCALL_TRACE|_TIF_SYSCALL_AUDIT|_TIF_SECCOMP),TI_flags(%ebp) jnz
> syscall_trace_entry cmpl $(nr_syscalls), %eax
>        jae syscall_badsys
> syscall_call:
>        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
> Lin
>

Hi Lin,

Thanks for the information. :)

One thing regarding that asmlinkage FAQ, does the author means process
kernel stack when he indicates the usage of CPU stack?

Also in file,
arch/x86/include/asm/linkage.h : -

/*
 * Make sure the compiler doesn't do anything stupid with the
 * arguments on the stack - they are owned by the *caller*, not
 * the callee. This just fools gcc into not spilling into them,
 * and keeps it from doing tailcall recursion and/or using the
 * stack slots for temporaries, since they are live and "used"
 * all the way to the end of the function.
 *
 * NOTE! On x86-64, all the arguments are in registers, so this
 * only matters on a 32-bit kernel.
 */

This comment states that it only happens for 32-bit arch and for 64 - bit
arch parameters are kept in registers itself.

Thats why for system_call assembly function, for 32-bit this SAVE_ALL method
is used and for 64-bit this SAVE_ALL method is not used.

Regards,
Rohan.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.kernelnewbies.org/pipermail/kernelnewbies/attachments/20110908/5e7f61dc/attachment-0001.html