Hi guys,

I need to find the size of the activation record of a procedure using the "address of" (&) operator...

Any idea how it's done ??

Thanks for your help

Boule

Hi guys,

I need to find the size of the activation record of a procedure using the "address of" (&) operator...

Any idea how it's done ??

Thanks for your help

Boule

what activation record and what procedure ?!!
post your code mate !

I need a general answer, not depending on any code...

see sizeof() operator -- but the size of a pointer is always the same on 32-bit compilers.

Hm.. Mr. Dragon, i think you are confusing it with something else. The OP wants the size of the "activation record" and not the variable.

For eg. when the program control enters the function, the whole function is pushed in stack by allocating it a stack frame, and the OP wants to know how to find the amount of space consumed by that procedure in the stack.

@Boule
I dont know why you want to find the "size" of activation record, coz that thing is pretty much transparent even to a C programmer and not brought into consideration unless you go in the Assembly lang or Operating system theory depths.
But just for some knowledge, see HERE

If that's what he wants, then its pretty small and depends on the processor and sometimes the compiler. Here is an example of how the compiler generates the startup code for a function on intel processors. Other processors will be different.

push sp
push ebp
push esi
push edi
mov bp,sp
sub sp,<size of local variables>

> I need a general answer, not depending on any code...
If you're looking to get things like the return address, base pointer and stack pointer say, then there is NO general answer.

It is very compiler specific, right down to which set of compiler flags you specify.

yeah i know it's usually transparent, but I need to generate a C code that would give me the size of the activation record of a procedure. sizeof() doesn't do that.

If I can find a way to access the various pointers (dynamic link, stack pointer, frame pointer...) I could manage, but I don't know how...

What are you trying to achieve here?
State your problem, not how to make your solution work.

Which OS / Compiler are you using?
Some compilers can report stack frame sizes by various means.

I'm trying to achieve just what a said: find the size of a procedure's AR... I'm under XP, using dev c++, but the C code should be independant of the os/compiler

the stack frame size is not fixed -- it depends on the parameters passed to the function, and whether the parameters are pushed onto the stack or passed in registers. Read the link -- it gives a much better explaination. What you are attempting to do in your original question just simply is not possible.

AFAIK, the AR of a procedure always starts with the return value. That's considering the stack fills from bottom to top, the return value would always be at the bottom. The size of the return value is fixed, since it's an address.

How about surtracting the return value of the procedure and the return value of the next procedure (which would be above the 1st one in the stack). Will that work ?

Although that may be true, the problem is how to determine which byte on the stack is the return value?

>>How about surtracting the return value of the procedure and the return value of the next procedure (which would be above the 1st one in the stack). Will that work ?

No because the contents of the stack are dynamic not static so the contents of the next procedure call are not even on the stack.

> I'm trying to achieve just what a said: find the size of a procedure's AR
But WHY???

These are good answers.
a) because the code is destined for an embedded system with very limited stack space, and I need to monitor how much stack space each function requires.
b) I'm writing some inter-language porting code, so I need to know how to arrange the stack to make proper function calls.

This is a bad answer
c) I'm writing some malware and I want to skip up the stack a couple of frames and overwrite the return address to get into my malware so I can do all sorts of nasty stuff.

> but the C code should be independant of the os/compiler
I'll say it again, since you seem to be hard of hearing.
There is NO portable way for you to find this out.

This article has been dead for over six months. Start a new discussion instead.