Doubt regarding asmlinkage
rohan puri
rohan.puri15 at gmail.com
Thu Sep 8 08:09:00 EDT 2011
On Thu, Sep 8, 2011 at 5:28 PM, Pei Lin <telent997 at gmail.com> wrote:
> 2011/9/8 rohan puri <rohan.puri15 at gmail.com>:
> >
> >
> > 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.
> Yes, x86-64 expand the general-purpose registers from 8 to 16
> The main features include:
> Pointers and long integers are 64 bits long. Integer arithmetic
> operations support 8, 16, 32, and 64-bit
> data types.
> The set of general-purpose registers is expanded from 8 to 16.
> Much of the program state is held in registers rather than on the
> stack. Integer and pointer procedure
> arguments (up to 6) are passed via registers. Some procedures do not
> need to access the stack at all.
> Conditional operations are implemented using conditional move
> instructions when possible, yielding
> better performance than traditional branching code.
> Floating-point operations are implemented using a register-oriented
> instruction set, rather than the
> stack-based approach supported by IA32.
>
> more information as below link:
> http://www.cs.cmu.edu/~fp/courses/15213-s07/misc/asm64-handout.pdf
>
>
> >
> > Regards,
> > Rohan.
> >
> >
> >
> >
> >
>
>
>
> --
> Best Regards
> Lin
>
Yes agreed, Thanks. :)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.kernelnewbies.org/pipermail/kernelnewbies/attachments/20110908/4131a456/attachment-0001.html
More information about the Kernelnewbies
mailing list