stack contents at function call

stack contents at function call

[Vadiraj C S]

  Hello Assembly Gurus

   I'm working on Assembly programming under linux from few days, here are some issues

 1.When a function call is made the parameters are pushed on to the stack and a a call
to the function is made. 

 Now the top of the stack is the return address, Please correct me if I'm wrong here,
and the parameters above it is the first parameter sent and so on..

 1. Is this OS dependent, or compiler dependent? 
 2. Does this sequence change when call from C language and call from assembly.

Cos I noticed difference with gcc(GNU compiler) and icc (Intell compiler)


 Help is needed urgent, 

Thanks in advance...



-- 

With Best Regards
 Vadiraj C S    

Re: stack contents at function call

[Frederic Marmond]

Hi,
Vadiraj C S wrote:

>  Hello Assembly Gurus
>
>   I'm working on Assembly programming under linux from few days, here are some issues
>
> 1.When a function call is made the parameters are pushed on to the stack and a a call
>to the function is made. 
>  
>
right in most systems compilators (x86 works that way, for example)

> Now the top of the stack is the return address, Please correct me if I'm wrong here,
>and the parameters above it is the first parameter sent and so on..
>
> 1. Is this OS dependent, or compiler dependent? 
>
It depends... ;)
Sure, it is NOT OS dependent. On Linux, for exemple, this may work 
different from hardware to an other.
For exemple, on x86, as there is not a lot of registers, all is passed 
on a single stack.
But on other architectures, wich have more registers, functions 
parameters are splitted in registers (integers and float registers) and 
in stack when there are no register free.
Now, if you want a program to interact with others, you may respect 
calling conventions.
Since it is most likely to occurs (programs call each others), you may 
guess compilers works the same way on a arch/OS.

> 2. Does this sequence change when call from C language and call from assembly.
>  
>
In Assembly, you can use what method you want to pass parameters. Look 
at interrupts, for exemple. They only use registers as parameters. So, 
you may create functions that only need registers as inputs, and other 
functions that need stack copying. It's up to your choice. But if you 
want to interract with other programs, you must respect the arch/OS 
convention.
Convention for C on x86 (I guess you are on this arch) is to pass 
arguments to stack. So, if you respect this convention from assembly, 
the sequence is the same.

But for C++ compilers, its a bit different (object's methods need a 
pointer to the instance, 'this').

You must also take care of alignement in stack.
C/C++ may align 32bits data. And most likely for 64bits data (long long, 
double).

>Cos I noticed difference with gcc(GNU compiler) and icc (Intell compiler)
>  
>
Can you give example? Be more precise...

>
> Help is needed urgent, 
>  
>
I'm ready to answer quickly today (french time)

Fred

>Thanks in advance...
>
>
>
>  
>

Re: stack contents at function call

[Vadiraj C S]

Mr Fred

> Convention for C on x86 (I guess you are on this arch) is to pass 
> arguments to stack. So, if you respect this convention from assembly, 
> the sequence is the same.
> 
   Yes I'm in x86 arch..
> 
> >Cos I noticed difference with gcc(GNU compiler) and icc (Intell compiler)
> >  
> >
> Can you give example? Be more precise...


void Func_call(unsigned long *a, unsigned shor int b, unsigned short int c)
{
 
        asm volatile ("pushl %esi");
        asm volatile ("pushl %edi");
        asm volatile ("pushl %ebp");
        asm volatile ("pushl %ebx");

 This below code works different in gcc and in icc
    {
        asm volatile ("movl 28(%esp),%esi");   
 
        asm volatile ("movw 32(%esp),%dx");

        asm volatile ("movl 36(%esp),%ebx");

    }
      

  Thought  it should be, 16 bytes for the pushed values, and 4 bytes for return address
so 24th byte should be the pointer to the first parameter a, GCC points to the perfect 
with 28th being referrenced to the first parameter. How is this...



and icc (intell compiler) it is what we expect it to be. esi is having the b value...

It was strange..

 
      asm volatile ("movl %esi,%ebp");

	  does ebp store any thing important, cos when  this statement is executed the parameter values get changed
while tracing from GDB. Please throw some light regarding ebp..

Thanks for the support Fred


-- 

		With knowledge comes power, and with power comes responsability.

 Regards
 Vadiraj C S

Re: stack contents at function call

[peter willy krause]

assuming ia32 architecture...
Q1)	return stack, if existent, is set up by the rsp. cpu;
	programming languages often put several data on the same stack as
	arguments to a subroutine call which, requires specific conventions.

users stack 'frame' can be set up by convention, which may be defined by a  
standard, e.g. 'posix' - which even assigns specific registers to certain 
tasks.

Q2)	basic return stack set up is not under programmers influence, 
	additional data may carefully be pushed/popped, e.g. "C"-ish 
	'arguments' or 'automatic' (i.e. locally available) variables &c.
	assembly leaves full control to the programmer, no implied conventions!
	(or else, mickeysoft...)

plain assembly is not bound to such conventions but, to different 
processor architectures.

in principle, cpu-s w. stacks usually store the return address (or some 
aequivalent data item) to top of stack and advance the stack pointer to 
the next, unused position; whether this 'push' goes towards lower (most 
commonly) or higher (e.g. some hp processors) addresses depends on the 
particular cpu design. some cpu-s can store additional data to the 
return-stack for interrupts or to supporting certain programming 
'languages', which got to be removed in an orderly manner, before 
accessing a previously stacked return address.

this basic procedure can be implemented in many different ways, thus 
depends on the particular cpu.

for instance, ia32 type cpu, 'protected mode', stores address after the 
<call disp> opcode which, will be removed by the subroutine 'ret' opr. 

posix documents re	http://www.lxhp.in-berlin.de/lhplinks.html#sysv
intel manuals		http://developer.intel.com/sites/developer/
"C" vs assembly code	http://www.lxhp.in-berlin.de/lhplinks.html#cas

best
	hp

Am Montag, 1. März 2004 07:48 schrieb Vadiraj C S:
>   Hello Assembly Gurus
>
>    I'm working on Assembly programming under linux from few days, here
> are some issues
>
>  1.When a function call is made the parameters are pushed on to the
> stack and a a call to the function is made.
>
>  Now the top of the stack is the return address, Please correct me if
> I'm wrong here, and the parameters above it is the first parameter sent
> and so on..
>
>  1. Is this OS dependent, or compiler dependent?
>  2. Does this sequence change when call from C language and call from
> assembly.
>
> Cos I noticed difference with gcc(GNU compiler) and icc (Intell
> compiler)
>
>
>  Help is needed urgent,
>
> Thanks in advance...

-- 
mail to 'hp': lx at lxhp : in-berlin : de

-
To unsubscribe from this list: send the line "unsubscribe linux-assembly" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: stack contents at function call

[Frederic Marmond]

Vadiraj C S wrote:

>Mr Fred
>
>  
>
>>Convention for C on x86 (I guess you are on this arch) is to pass 
>>arguments to stack. So, if you respect this convention from assembly, 
>>the sequence is the same.
>>
>>    
>>
>   Yes I'm in x86 arch..
>  
>
>>>Cos I noticed difference with gcc(GNU compiler) and icc (Intell compiler)
>>> 
>>>
>>>      
>>>
>>Can you give example? Be more precise...
>>    
>>
>
>
>void Func_call(unsigned long *a, unsigned shor int b, unsigned short int c)
>{
> 
>        asm volatile ("pushl %esi");
>        asm volatile ("pushl %edi");
>        asm volatile ("pushl %ebp");
>        asm volatile ("pushl %ebx");
>
> This below code works different in gcc and in icc
>    {
>        asm volatile ("movl 28(%esp),%esi");   
> 
>        asm volatile ("movw 32(%esp),%dx");
>
>        asm volatile ("movl 36(%esp),%ebx");
>
>    }
>      
>
>  Thought  it should be, 16 bytes for the pushed values, and 4 bytes for return address
>so 24th byte should be the pointer to the first parameter a, GCC points to the perfect 
>with 28th being referrenced to the first parameter. How is this...
>  
>
I agree it seems strange.
But:
- can you give the entire function?
    If you use any temporary data in your function, its memory will be 
reserved on the stack (and then, be inserted before your first "pushl %esi")
- can you create a helloworld.c that contains this function, called in 
the main, and compile it with the '--save-temps' option?
    With gcc-3.x, it will create a helloworld.s file, that is the 
assembly generated file from your helloworld.c
    We will see better what append

>
>
>and icc (intell compiler) it is what we expect it to be. esi is having the b value...
>
>It was strange..
>
> 
>      asm volatile ("movl %esi,%ebp");
>
>	  does ebp store any thing important, cos when  this statement is executed the parameter values get changed
>while tracing from GDB. Please throw some light regarding ebp..
>  
>
The function of ebp is to keep track of the local data on stack.
Generaly, you set ebp to esp when entering the function, and use it to 
reference your local data.
Then, if you push/pop things (affect esp) the data will be always at the 
same place regarding ebp.
for exemple:
    push %ebx
    push %edx
    call foo_function
    ...
foo_function:
    mov %esp,%ebp
        4(%ebp)   => refer to pushed edx
       4(%esp)    => refer to pushed edx
    push   %eax
        4(%ebp)     still refer to the pushed edx
        4(%esp)   doesn't refer to pushed edx anymore

>Thanks for the support Fred
>  
>
You're welcome, I'm at work and have nothing to do for now...
boring! ;)

Fred

>
>  
>

Re: stack contents at function call

[Frederic Marmond]

Hi,
Did you find the problem?
I would appreciate feed-backs, as I don't see what may differ from intel 
and gcc...
If you find the explanation, it would be nice to share it!
And if you didn't find, just send me the generated assembly (see at the 
end of my last reply) I may be in some help...

Fred

Frederic Marmond wrote:

> Vadiraj C S wrote:
>
>> Mr Fred
>>
>>  
>>
>>> Convention for C on x86 (I guess you are on this arch) is to pass 
>>> arguments to stack. So, if you respect this convention from 
>>> assembly, the sequence is the same.
>>>
>>>   
>>
>>   Yes I'm in x86 arch..
>>  
>>
>>>> Cos I noticed difference with gcc(GNU compiler) and icc (Intell 
>>>> compiler)
>>>>
>>>>
>>>>     
>>>
>>> Can you give example? Be more precise...
>>>   
>>
>>
>>
>> void Func_call(unsigned long *a, unsigned shor int b, unsigned short 
>> int c)
>> {
>>
>>        asm volatile ("pushl %esi");
>>        asm volatile ("pushl %edi");
>>        asm volatile ("pushl %ebp");
>>        asm volatile ("pushl %ebx");
>>
>> This below code works different in gcc and in icc
>>    {
>>        asm volatile ("movl 28(%esp),%esi");  
>>        asm volatile ("movw 32(%esp),%dx");
>>
>>        asm volatile ("movl 36(%esp),%ebx");
>>
>>    }
>>     
>>  Thought  it should be, 16 bytes for the pushed values, and 4 bytes 
>> for return address
>> so 24th byte should be the pointer to the first parameter a, GCC 
>> points to the perfect with 28th being referrenced to the first 
>> parameter. How is this...
>>  
>>
> I agree it seems strange.
> But:
> - can you give the entire function?
>    If you use any temporary data in your function, its memory will be 
> reserved on the stack (and then, be inserted before your first "pushl 
> %esi")
> - can you create a helloworld.c that contains this function, called in 
> the main, and compile it with the '--save-temps' option?
>    With gcc-3.x, it will create a helloworld.s file, that is the 
> assembly generated file from your helloworld.c
>    We will see better what append
>
>>
>>
>> and icc (intell compiler) it is what we expect it to be. esi is 
>> having the b value...
>>
>> It was strange..
>>
>>
>>      asm volatile ("movl %esi,%ebp");
>>
>>       does ebp store any thing important, cos when  this statement is 
>> executed the parameter values get changed
>> while tracing from GDB. Please throw some light regarding ebp..
>>  
>>
> The function of ebp is to keep track of the local data on stack.
> Generaly, you set ebp to esp when entering the function, and use it to 
> reference your local data.
> Then, if you push/pop things (affect esp) the data will be always at 
> the same place regarding ebp.
> for exemple:
>    push %ebx
>    push %edx
>    call foo_function
>    ...
> foo_function:
>    mov %esp,%ebp
>        4(%ebp)   => refer to pushed edx
>       4(%esp)    => refer to pushed edx
>    push   %eax
>        4(%ebp)     still refer to the pushed edx
>        4(%esp)   doesn't refer to pushed edx anymore
>
>> Thanks for the support Fred
>>  
>>
> You're welcome, I'm at work and have nothing to do for now...
> boring! ;)
>
> Fred
>
>>
>>  
>>
>
>
>

Re: stack contents at function call

[Frederic Marmond]

Vadiraj C S wrote:

>  the displace which is given above is specific to gcc and in windows it would 
>be something else, I dint get time to research on this much but the difference is
>that, I had to change it 24, 28 and 32 to make it work on icc. 
>
> And yes this asm code is call from an insline asm itself the sequence of code before 
>the call is this
>
>  asm volatile ("push %ebx") //which is the last parameter to Func_call
>  asm volatile ("push %edx") // which is the middle one b
>  asm volatile ("push %esi") // which is the address of a
>  asm volatile ("call Func_call") ;
>
>
> I'm sorry for the delay in response, I would appreciate if you can put some information
>on this at your free time..
>
>
>  
>
Hum, if you send your code parts to parts, it is a bit difficult to see 
what you are doing...
If I understand the (very few) parts you gave, the 4 bytes added by gcc 
to stack are the 'Func_call'.
You can check it be compiling with -save-temps and see the assembly 
generated code.

If you really want me to confirm, please, create a simple hello-world 
that reproduce this behaviour, compil it with -save-temps option, and 
send me both the .c and the .s files.
Then, I think I would have enough data to tell you exactly what appens 
(and how change it if you want the same code to work the same in windows 
and linux)

Fred
(PS: and please, keep reply to the community, as your problem and its 
solution may be usefull for somebody in the futur. Thanks)




Vadiraj C S wrote:

> Mr Fred,
>
>
>  
>
>>Hi,
>>Did you find the problem?
>>I would appreciate feed-backs, as I don't see what may differ from intel 
>>and gcc...
>>    
>>
>
>   Yes there is difference in the displacement from the ebp at call values 
>in gcc and intel.
>
>
>  
>
>>If you find the explanation, it would be nice to share it!
>>And if you didn't find, just send me the generated assembly (see at the 
>>end of my last reply) I may be in some help...
>>
>>    
>>
>
>
>void Func_call(unsigned long *a, unsigned shor int b, unsigned short 
>  
>
>>>>int c)
>>>>{
>>>>
>>>>       asm volatile ("pushl %esi");
>>>>       asm volatile ("pushl %edi");
>>>>       asm volatile ("pushl %ebp");
>>>>       asm volatile ("pushl %ebx");
>>>>
>>>>This below code works different in gcc and in icc
>>>>   {
>>>>       asm volatile ("movl 28(%esp),%esi");  
>>>>       asm volatile ("movw 32(%esp),%dx");
>>>>
>>>>       asm volatile ("movl 36(%esp),%ebx");
>>>>
>>>>   }
>>>>
>>>>        
>>>>
>
>
>  the displace which is given above is specific to gcc and in windows it would 
>be something else, I dint get time to research on this much but the difference is
>that, I had to change it 24, 28 and 32 to make it work on icc. 
>
> And yes this asm code is call from an insline asm itself the sequence of code before 
>the call is this
>
>  asm volatile ("push %ebx") //which is the last parameter to Func_call
>  asm volatile ("push %edx") // which is the middle one b
>  asm volatile ("push %esi") // which is the address of a
>  asm volatile ("call Func_call") ;
>
>
> I'm sorry for the delay in response, I would appreciate if you can put some information
>on this at your free time..
>
>
>  
>