From mboxrd@z Thu Jan 1 00:00:00 1970 From: rohan.puri15@gmail.com (rohan puri) Date: Thu, 8 Sep 2011 14:49:15 +0530 Subject: Doubt regarding asmlinkage In-Reply-To: References: Message-ID: To: kernelnewbies@lists.kernelnewbies.org List-Id: kernelnewbies.lists.kernelnewbies.org On Thu, Sep 8, 2011 at 12:47 PM, Pei Lin wrote: > 2011/9/8 rohan puri : > > > > > > 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 > 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 > > > On Sat, 18 Jun 2005 22:00:39 +0800 > Roy Lee 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