Why is there conflicting information out there for asmlinkage ?
I thought that all C programs normally use the stack for function calls. That's why in most languages if you are stuck in an infinite recursion you get a "Stack Overflow Error". If that is true, then what is so special about asmlinkage, it tells the program to look for variables in the stack rather than registers. The runtime does not look for values in the register in the first place. 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.
What's even more strange is that when you learn that it is implemented using regparam in x86. https://qr.ae/pNy1wL The documentation for regparam is as follows: https://gcc.gnu.org/onlinedocs/gcc/x86-Function-Attributes.html#x86-Function...
On x86-32 targets, the regparm attribute causes the compiler to pass arguments number one to number if they are of integral type in registers EAX, EDX, and ECX instead of on the stack. Functions that take a variable number of arguments continue to be passed all of their arguments on the stack.
It says just the opposite. What is going on ? Which is correct the stack or the registers ? Why is there conflicting info out there ? -- Regards, Sreyan Chakravarty
On Wed, May 6, 2020 at 6:24 PM Sreyan Chakravarty <sreyan32@gmail.com> wrote:
I thought that all C programs normally use the stack for function calls. That's why in most languages if you are stuck in an infinite recursion you get a "Stack Overflow Error".
If that is true, then what is so special about asmlinkage, it tells the program to look for variables in the stack rather than registers. The runtime does not look for values in the register in the first place.
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.
What's even more strange is that when you learn that it is implemented using regparam in x86. https://qr.ae/pNy1wL
The documentation for regparam is as follows: https://gcc.gnu.org/onlinedocs/gcc/x86-Function-Attributes.html#x86-Function...
On x86-32 targets, the regparm attribute causes the compiler to pass arguments number one to number if they are of integral type in registers EAX, EDX, and ECX instead of on the stack. Functions that take a variable number of arguments continue to be passed all of their arguments on the stack.
It says just the opposite.
What is going on ? Which is correct the stack or the registers ?
Why is there conflicting info out there ? -- Regards, Sreyan Chakravarty _______________________________________________ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
My 2 cents... asmlinkage expands to regparam(0). This limits all arguments to be passed on stack.
On Wed, May 06, 2020 at 06:21:54PM +0530, Sreyan Chakravarty wrote:
I thought that all C programs normally use the stack for function calls. That's why in most languages if you are stuck in an infinite recursion you get a "Stack Overflow Error".
Not really, depends on the calling convention used. For example: https://en.wikipedia.org/wiki/X86_calling_conventions#System_V_AMD64_ABI first six parameters are passed using registers. For system calls it is similar: http://man7.org/linux/man-pages/man2/syscall.2.html -- Valentin
participants (3)
-
arshad hussain -
Sreyan Chakravarty -
Valentin Vidić