<br><br><div class="gmail_quote">On Thu, Sep 8, 2011 at 5:28 PM, Pei Lin <span dir="ltr"><<a href="mailto:telent997@gmail.com">telent997@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<div><div></div><div class="h5">2011/9/8 rohan puri <<a href="mailto:rohan.puri15@gmail.com">rohan.puri15@gmail.com</a>>:<br>
><br>
><br>
> On Thu, Sep 8, 2011 at 12:47 PM, Pei Lin <<a href="mailto:telent997@gmail.com">telent997@gmail.com</a>> wrote:<br>
>><br>
>> 2011/9/8 rohan puri <<a href="mailto:rohan.puri15@gmail.com">rohan.puri15@gmail.com</a>>:<br>
>> ><br>
>> ><br>
>> > On Thu, Sep 8, 2011 at 9:50 AM, Mulyadi Santosa<br>
>> > <<a href="mailto:mulyadi.santosa@gmail.com">mulyadi.santosa@gmail.com</a>><br>
>> > wrote:<br>
>> >><br>
>> >> Hi :)<br>
>> >><br>
>> >> On Thu, Sep 8, 2011 at 10:40, rohan puri <<a href="mailto:rohan.puri15@gmail.com">rohan.puri15@gmail.com</a>><br>
>> >> wrote:<br>
>> >> > Hi Mulyadi,<br>
>> >> ><br>
>> >> > Thanks for the response. I do agree with the issue concerning the<br>
>> >> > no.of<br>
>> >> > registers available are less for 32 bit to that of 64 bit.<br>
>> >> ><br>
>> >> > But even in this case if parameters are more than the no of register<br>
>> >> > for<br>
>> >> > 32<br>
>> >> > bit, then also before executing int 80h interrupt it stores the<br>
>> >> > parameters<br>
>> >> > in the register and after that system call dispatcher puts them on<br>
>> >> > the<br>
>> >> > kernel stack of that process. So, how the case where more than no of<br>
>> >> > registers are the parameters to the system call is handled.<br>
>> >><br>
>> >><br>
>> >> Please don't top post :)<br>
>> >><br>
>> >> Regarding passing the parameters when it is more than number of<br>
>> >> registers used in x86 32 bit, AFAIK it's using EDX to contain the<br>
>> >> address of user space memory that contains the data, later it will be<br>
>> >> copied to kernel stack IIRC.<br>
>> >><br>
>> >> --<br>
>> >> regards,<br>
>> >><br>
>> >> Mulyadi Santosa<br>
>> >> Freelance Linux trainer and consultant<br>
>> >><br>
>> >> blog: <a href="http://the-hydra.blogspot.com" target="_blank">the-hydra.blogspot.com</a><br>
>> >> training: <a href="http://mulyaditraining.blogspot.com" target="_blank">mulyaditraining.blogspot.com</a><br>
>> ><br>
>> > Sorry for top posting. :)<br>
>> ><br>
>> > Got it now. Thanks.<br>
>> ><br>
>> > Regards,<br>
>> > Rohan.<br>
>> ><br>
>> > _______________________________________________<br>
>> > Kernelnewbies mailing list<br>
>> > <a href="mailto:Kernelnewbies@kernelnewbies.org">Kernelnewbies@kernelnewbies.org</a><br>
>> > <a href="http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies" target="_blank">http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies</a><br>
>> ><br>
>> ><br>
>> Kernel newbies website crashed? can not login, only get the snapshot as<br>
>> below.<br>
>> <a href="http://kernelnewbies.org/FAQ/asmlinkage" target="_blank">http://kernelnewbies.org/FAQ/asmlinkage</a><br>
>><br>
>> FAQ/asmlinkage<br>
>> What is asmlinkage?<br>
>> The asmlinkage tag is one other thing that we should observe about<br>
>> this simple function. This is a #define for some gcc magic that tells<br>
>> the compiler that the function should not expect to find any of its<br>
>> arguments in registers (a common optimization), but only on the CPU's<br>
>> stack. Recall our earlier assertion that system_call consumes its<br>
>> first argument, the system call number, and allows up to four more<br>
>> arguments that are passed along to the real system call. system_call<br>
>> achieves this feat simply by leaving its other arguments (which were<br>
>> passed to it in registers) on the stack. All system calls are marked<br>
>> with the asmlinkage tag, so they all look to the stack for arguments.<br>
>> Of course, in sys_ni_syscall's case, this doesn't make any difference,<br>
>> because sys_ni_syscall doesn't take any arguments, but it's an issue<br>
>> for most other system calls. And, because you'll be seeing asmlinkage<br>
>> in front of many other functions, I thought you should know what it<br>
>> was about.<br>
>><br>
>> It is also used to allow calling a function from assembly files.<br>
>><br>
>> There also have explicit explanation in the kernel maillist archive.<br>
>> Date: Sat, 18 Jun 2005 16:29:01 +0200<br>
>> To: Roy Lee <<a href="mailto:roylee17@gmail.com">roylee17@gmail.com</a>><br>
>><br>
>><br>
>> On Sat, 18 Jun 2005 22:00:39 +0800<br>
>> Roy Lee <<a href="mailto:roylee17@gmail.com">roylee17@gmail.com</a>> wrote:<br>
>><br>
>><br>
>> > It says that "To tell a compiler not to use the argument in the<br>
>> > registers". but the syscall's argument does pass the arguments though<br>
>> > registers, doesn't it?<br>
>><br>
>><br>
>> yes, user space programs put arguments in registers (ebx, ecx, edx...) but<br>
>> see what happens later...<br>
>><br>
>><br>
>> 1) user space programs do something like this:<br>
>><br>
>><br>
>> mov $SYSCALLNUMER, %eax<br>
>> mov $ARG1, %ebx<br>
>> mov $ARG2, %ecx<br>
>> ...<br>
>> int $0x80 ------ go to kernel syscall handler ---><br>
>><br>
>><br>
>><br>
>> ---> arch(i386/kernel/entry.S:<br>
>><br>
>><br>
>> ....<br>
>> # system call handler stub<br>
>> ENTRY(system_call)<br>
>> pushl %eax # save orig_eax<br>
>> SAVE_ALL<br>
>> GET_THREAD_INFO(%ebp)<br>
>> # system call tracing in operation<br>
>> /* Note, _TIF_SECCOMP is bit number 8, and so it needs testw<br>
>> and not testb<br>
>> */ testw<br>
>> $(_TIF_SYSCALL_TRACE|_TIF_SYSCALL_AUDIT|_TIF_SECCOMP),TI_flags(%ebp) jnz<br>
>> syscall_trace_entry cmpl $(nr_syscalls), %eax<br>
>> jae syscall_badsys<br>
>> syscall_call:<br>
>> call *sys_call_table(,%eax,4)<br>
>> movl %eax,EAX(%esp) # store the return value<br>
>> ...<br>
>><br>
>><br>
>><br>
>> notice just these 2 things:<br>
>><br>
>><br>
>> 1) SAVE_ALL ---> it's a MACRO that do this:<br>
>><br>
>><br>
>> #define SAVE_ALL \<br>
>> cld; \<br>
>> pushl %es; \<br>
>> pushl %ds; \<br>
>> pushl %eax; \<br>
>> pushl %ebp; \<br>
>> pushl %edi; \<br>
>> pushl %esi; \ ....<br>
>> pushl %edx; \ > ARG3 <<br>
>> pushl %ecx; \ > ARG2 <<br>
>> pushl %ebx; \ > ARG1 <<br>
>> movl $(__USER_DS), %edx; \<br>
>> movl %edx, %ds; \<br>
>> movl %edx, %es;<br>
>><br>
>><br>
>> 2) call *sys_call_table(,%eax,4)<br>
>><br>
>><br>
>> this calls the "C" system call function<br>
>><br>
>><br>
>><br>
>> So, since the arguments are passed on the stack (see SAVE_ALL) the "C"<br>
>> function MUST take them from the stack.<br>
>><br>
>><br>
>> --<br>
>> Best Regards<br>
>> Lin<br>
><br>
> Hi Lin,<br>
><br>
> Thanks for the information. :)<br>
><br>
> One thing regarding that asmlinkage FAQ, does the author means process<br>
> kernel stack when he indicates the usage of CPU stack?<br>
><br>
> Also in file,<br>
> arch/x86/include/asm/linkage.h : -<br>
><br>
> /*<br>
> * Make sure the compiler doesn't do anything stupid with the<br>
> * arguments on the stack - they are owned by the *caller*, not<br>
> * the callee. This just fools gcc into not spilling into them,<br>
> * and keeps it from doing tailcall recursion and/or using the<br>
> * stack slots for temporaries, since they are live and "used"<br>
> * all the way to the end of the function.<br>
> *<br>
> * NOTE! On x86-64, all the arguments are in registers, so this<br>
> * only matters on a 32-bit kernel.<br>
> */<br>
><br>
> This comment states that it only happens for 32-bit arch and for 64 - bit<br>
> arch parameters are kept in registers itself.<br>
><br>
> Thats why for system_call assembly function, for 32-bit this SAVE_ALL method<br>
> is used and for 64-bit this SAVE_ALL method is not used.<br>
</div></div>Yes, x86-64 expand the general-purpose registers from 8 to 16<br>
The main features include:<br>
Pointers and long integers are 64 bits long. Integer arithmetic<br>
operations support 8, 16, 32, and 64-bit<br>
data types.<br>
The set of general-purpose registers is expanded from 8 to 16.<br>
Much of the program state is held in registers rather than on the<br>
stack. Integer and pointer procedure<br>
arguments (up to 6) are passed via registers. Some procedures do not<br>
need to access the stack at all.<br>
Conditional operations are implemented using conditional move<br>
instructions when possible, yielding<br>
better performance than traditional branching code.<br>
Floating-point operations are implemented using a register-oriented<br>
instruction set, rather than the<br>
stack-based approach supported by IA32.<br>
<br>
more information as below link:<br>
<a href="http://www.cs.cmu.edu/%7Efp/courses/15213-s07/misc/asm64-handout.pdf" target="_blank">http://www.cs.cmu.edu/~fp/courses/15213-s07/misc/asm64-handout.pdf</a><br>
<br>
<br>
><br>
> Regards,<br>
> Rohan.<br>
><br>
><br>
><br>
><br>
><br>
<br>
<br>
<br>
--<br>
Best Regards<br>
<font color="#888888">Lin<br>
</font></blockquote></div><br>Yes agreed, Thanks. :)<br>