* Doubt regarding asmlinkage [not found] <CALJfu6OcCd7vdcEG+=PYAY2MrKyqHw7p5O2KNN7s0s7pxO5R+w@mail.gmail.com> @ 2011-09-07 12:09 ` rohan puri 2011-09-08 2:42 ` Mulyadi Santosa 0 siblings, 1 reply; 9+ messages in thread From: rohan puri @ 2011-09-07 12:09 UTC (permalink / raw) To: kernelnewbies Hi All, asmlinkage is used in front of the each system call prototype. For x86 arch it indicates that the the parameters are on stack instead of the registers and for x86_64 arch the parameters are in registers only. Doubt i have is whats the need for 32-bit intel arch to put parameters on stack and not registers in a way similar to x86_64? Regards, Rohan. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.kernelnewbies.org/pipermail/kernelnewbies/attachments/20110907/5f3cd7f9/attachment.html ^ permalink raw reply [flat|nested] 9+ messages in thread
* Doubt regarding asmlinkage 2011-09-07 12:09 ` Doubt regarding asmlinkage rohan puri @ 2011-09-08 2:42 ` Mulyadi Santosa 2011-09-08 3:40 ` rohan puri 0 siblings, 1 reply; 9+ messages in thread From: Mulyadi Santosa @ 2011-09-08 2:42 UTC (permalink / raw) To: kernelnewbies Hi Rohan :) On Wed, Sep 7, 2011 at 19:09, rohan puri <rohan.puri15@gmail.com> wrote: > Doubt i have is whats the need for 32-bit intel arch to put parameters on > stack and not registers in a way similar to x86_64? well, if you need to pass so many parameters, then x86 32 bit registers can not cope with that. You only have EAX, EBX, ECX, EDX, ESI, EDI as far as I could remember. probably in 64 bit, registers is way more so it's still possible to put them in registers, which is of course the fastest way to access them. -- regards, Mulyadi Santosa Freelance Linux trainer and consultant blog: the-hydra.blogspot.com training: mulyaditraining.blogspot.com ^ permalink raw reply [flat|nested] 9+ messages in thread
* Doubt regarding asmlinkage 2011-09-08 2:42 ` Mulyadi Santosa @ 2011-09-08 3:40 ` rohan puri 2011-09-08 4:20 ` Mulyadi Santosa 0 siblings, 1 reply; 9+ messages in thread From: rohan puri @ 2011-09-08 3:40 UTC (permalink / raw) To: kernelnewbies 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. Regards, Rohan. On Thu, Sep 8, 2011 at 8:12 AM, Mulyadi Santosa <mulyadi.santosa@gmail.com>wrote: > Hi Rohan :) > > On Wed, Sep 7, 2011 at 19:09, rohan puri <rohan.puri15@gmail.com> wrote: > > Doubt i have is whats the need for 32-bit intel arch to put parameters on > > stack and not registers in a way similar to x86_64? > > well, if you need to pass so many parameters, then x86 32 bit > registers can not cope with that. You only have EAX, EBX, ECX, EDX, > ESI, EDI as far as I could remember. > > probably in 64 bit, registers is way more so it's still possible to > put them in registers, which is of course the fastest way to access > them. > > -- > regards, > > Mulyadi Santosa > Freelance Linux trainer and consultant > > blog: the-hydra.blogspot.com > training: mulyaditraining.blogspot.com > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.kernelnewbies.org/pipermail/kernelnewbies/attachments/20110908/cd314fe5/attachment.html ^ permalink raw reply [flat|nested] 9+ messages in thread
* Doubt regarding asmlinkage 2011-09-08 3:40 ` rohan puri @ 2011-09-08 4:20 ` Mulyadi Santosa 2011-09-08 5:13 ` rohan puri 0 siblings, 1 reply; 9+ messages in thread From: Mulyadi Santosa @ 2011-09-08 4:20 UTC (permalink / raw) To: kernelnewbies Hi :) On Thu, Sep 8, 2011 at 10:40, rohan puri <rohan.puri15@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 ^ permalink raw reply [flat|nested] 9+ messages in thread
* Doubt regarding asmlinkage 2011-09-08 4:20 ` Mulyadi Santosa @ 2011-09-08 5:13 ` rohan puri 2011-09-08 7:17 ` Pei Lin 0 siblings, 1 reply; 9+ messages in thread From: rohan puri @ 2011-09-08 5:13 UTC (permalink / raw) To: kernelnewbies On Thu, Sep 8, 2011 at 9:50 AM, Mulyadi Santosa <mulyadi.santosa@gmail.com>wrote: > Hi :) > > On Thu, Sep 8, 2011 at 10:40, rohan puri <rohan.puri15@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. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.kernelnewbies.org/pipermail/kernelnewbies/attachments/20110908/542e0756/attachment.html ^ permalink raw reply [flat|nested] 9+ messages in thread
* Doubt regarding asmlinkage 2011-09-08 5:13 ` rohan puri @ 2011-09-08 7:17 ` Pei Lin 2011-09-08 9:19 ` rohan puri 0 siblings, 1 reply; 9+ messages in thread From: Pei Lin @ 2011-09-08 7:17 UTC (permalink / raw) To: kernelnewbies 2011/9/8 rohan puri <rohan.puri15@gmail.com>: > > > On Thu, Sep 8, 2011 at 9:50 AM, Mulyadi Santosa <mulyadi.santosa@gmail.com> > wrote: >> >> Hi :) >> >> On Thu, Sep 8, 2011 at 10:40, rohan puri <rohan.puri15@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@gmail.com> On Sat, 18 Jun 2005 22:00:39 +0800 Roy Lee <roylee17@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 ^ permalink raw reply [flat|nested] 9+ messages in thread
* Doubt regarding asmlinkage 2011-09-08 7:17 ` Pei Lin @ 2011-09-08 9:19 ` rohan puri 2011-09-08 11:58 ` Pei Lin 0 siblings, 1 reply; 9+ messages in thread From: rohan puri @ 2011-09-08 9:19 UTC (permalink / raw) To: kernelnewbies On Thu, Sep 8, 2011 at 12:47 PM, Pei Lin <telent997@gmail.com> wrote: > 2011/9/8 rohan puri <rohan.puri15@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@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@gmail.com> > > > On Sat, 18 Jun 2005 22:00:39 +0800 > Roy Lee <roylee17@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 ^ permalink raw reply [flat|nested] 9+ messages in thread
* Doubt regarding asmlinkage 2011-09-08 9:19 ` rohan puri @ 2011-09-08 11:58 ` Pei Lin 2011-09-08 12:09 ` rohan puri 0 siblings, 1 reply; 9+ messages in thread From: Pei Lin @ 2011-09-08 11:58 UTC (permalink / raw) To: kernelnewbies 2011/9/8 rohan puri <rohan.puri15@gmail.com>: > > > On Thu, Sep 8, 2011 at 12:47 PM, Pei Lin <telent997@gmail.com> wrote: >> >> 2011/9/8 rohan puri <rohan.puri15@gmail.com>: >> > >> > >> > On Thu, Sep 8, 2011 at 9:50 AM, Mulyadi Santosa >> > <mulyadi.santosa@gmail.com> >> > wrote: >> >> >> >> Hi :) >> >> >> >> On Thu, Sep 8, 2011 at 10:40, rohan puri <rohan.puri15@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@gmail.com> >> >> >> On Sat, 18 Jun 2005 22:00:39 +0800 >> Roy Lee <roylee17@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: \x0f Pointers and long integers are 64 bits long. Integer arithmetic operations support 8, 16, 32, and 64-bit data types. \x0f The set of general-purpose registers is expanded from 8 to 16. \x0f 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. \x0f Conditional operations are implemented using conditional move instructions when possible, yielding better performance than traditional branching code. \x0f 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 ^ permalink raw reply [flat|nested] 9+ messages in thread
* Doubt regarding asmlinkage 2011-09-08 11:58 ` Pei Lin @ 2011-09-08 12:09 ` rohan puri 0 siblings, 0 replies; 9+ messages in thread From: rohan puri @ 2011-09-08 12:09 UTC (permalink / raw) To: kernelnewbies On Thu, Sep 8, 2011 at 5:28 PM, Pei Lin <telent997@gmail.com> wrote: > 2011/9/8 rohan puri <rohan.puri15@gmail.com>: > > > > > > On Thu, Sep 8, 2011 at 12:47 PM, Pei Lin <telent997@gmail.com> wrote: > >> > >> 2011/9/8 rohan puri <rohan.puri15@gmail.com>: > >> > > >> > > >> > On Thu, Sep 8, 2011 at 9:50 AM, Mulyadi Santosa > >> > <mulyadi.santosa@gmail.com> > >> > wrote: > >> >> > >> >> Hi :) > >> >> > >> >> On Thu, Sep 8, 2011 at 10:40, rohan puri <rohan.puri15@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@gmail.com> > >> > >> > >> On Sat, 18 Jun 2005 22:00:39 +0800 > >> Roy Lee <roylee17@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 ^ permalink raw reply [flat|nested] 9+ messages in thread
end of thread, other threads:[~2011-09-08 12:09 UTC | newest] Thread overview: 9+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- [not found] <CALJfu6OcCd7vdcEG+=PYAY2MrKyqHw7p5O2KNN7s0s7pxO5R+w@mail.gmail.com> 2011-09-07 12:09 ` Doubt regarding asmlinkage rohan puri 2011-09-08 2:42 ` Mulyadi Santosa 2011-09-08 3:40 ` rohan puri 2011-09-08 4:20 ` Mulyadi Santosa 2011-09-08 5:13 ` rohan puri 2011-09-08 7:17 ` Pei Lin 2011-09-08 9:19 ` rohan puri 2011-09-08 11:58 ` Pei Lin 2011-09-08 12:09 ` rohan puri
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.