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@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.