<br><br><div class="gmail_quote">On Thu, Sep 8, 2011 at 12:47 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;">
2011/9/8 rohan puri <<a href="mailto:rohan.puri15@gmail.com">rohan.puri15@gmail.com</a>>:<br>
<div><div></div><div class="h5">><br>
><br>
> On Thu, Sep 8, 2011 at 9:50 AM, Mulyadi Santosa <<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>> wrote:<br>
>> > Hi Mulyadi,<br>
>> ><br>
>> > Thanks for the response. I do agree with the issue concerning the 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 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 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>
</div></div>> _______________________________________________<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 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>
<font color="#888888">Lin<br>
</font></blockquote></div><br>Hi Lin,<br>
<br>
Thanks for the information. :)<br>
<br>
One thing regarding that asmlinkage FAQ, does the author means process 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 arch parameters are kept in registers itself.<br>
<br>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.<br><br>Regards,<br>Rohan.<br><br><br><br><br>