Will the compiler produce the same code for both of these statements?
foo1(int* val){(*val)++;}
foo2(int &val){val++;}
Will it simply write a pointer into the parameter part of foo's stack frame? Or, in the second case, will the callers' and foos' stack frames somehow overlap such that the callers' local variable takes the same memory on the stack as the parameter for foo?
Those two calls should generate exactly the same code, unless you have some kind of weird compiler.
It depends.
The code generated for both will be equivalent if not identical on most platforms if compiled to a library.
Any good compiler will inline such a small function, so it is quite possible that rather than getting the address of something on the stack incrementing the pointed-to value, it will instead increment the value directly. Any inlined function's stack frame is embedded in the caller's stack frame, so the will overlap in that case.
The stacks cannot be made to overlap.
Consider that the argument could be a global, a heap object, or even if stored in the stack it could be not the very last element. Depending on the calling convention, other elements might be placed in between one stack frame and the parameters passed into the function (i.e. return address)...
And note that even if nothing was added in the stack, the decision cannot be made while compiling the function, but rather when the compiler is processing the calling function. Once the function is compiled, it will not change depending on where it is called from.
regarding overlapping of stack frames I found the following info here
:
For some purposes, the stack frame of a subroutine and that of its caller can be considered to overlap, the overlap consisting of the area where the parameters are passed from the caller to the callee. In some environments, the caller pushes each argument onto the stack, thus extending its stack frame, then invokes the callee. In other environments, the caller has a preallocated area at the top of its stack frame to hold the arguments it supplies to other subroutines it calls. This area is sometimes termed the outgoing arguments area or callout area. Under this approach, the size of the area is calculated by the compiler to be the largest needed by any called subroutine.
So in your case if only variables in local scopes of caller functions are passed to foo2 overlapping thing may be possible!
Related
I'm trying to modify/replace the parameter value of a function. Here's the stack and the highlighted location is the target.
(esp + 8) (struct sockaddr)
I'm executing inline assembly with a hooked function. Should I modify/replace the value once it is already on stack or before the params are even pushed?
Anything I should be aware of?
If you're hooking a function, it means that your own function was called with the original parameters and you may forward these parameters (changed or not) to the original function at some point. It's generally easier to change the parameters you receive without copying and pass them along. If you're doing user-land to user-land or kernel-land to kernel-land hooking, then you may NOT want to touch the original process/kernel memory pointers - copy for safety.
I want to know that when we call a function by value it makes a copy of the variable , but where in memory this copy of variable is stored
It's on the stack typically, before the pointer for the function call or the stack frame of the function. I don't know if this is required by the standard, but it's probably universally done.
So take this example:
int f(myClass byVal)
{
int b;
...
};
...
myClass myInst;
int val = f(myInst)
I'd expect the stack to look like at the point of the ellipsis inside of f:
<top> b (stack frame inside of f)
pointer to f
temp copy of myInst
myInst (stack frame of outer function).
...
When f returns, the stack is cleaned up to the frame of the enclosing function.
It's worth noting jogojapan's comment that optimization can cause changes, including putting some data in the machines internal registers. You'd never want to count on internal details like this, but it's good to understand the mechanisms in common use.
Like Codie CodeMonkey said, on most current computers, the copy will be on the stack. However, there are notable exceptions:
On platforms with a decent amount of registers (the old PowerPC and the entire Power series are an example, another one is the Sparc, I would define "decent amount" to mean at least 32 registers), the copies are actually made from one register to another register. On these platforms, there are strict rules, which registers a function may change and which not. Local variables are typically held in the registers which may not be changed by any called functions, so no memory access is necessary for them. Only, when the called function decides that it needs to use some of the registers it must not change, will it save the contents of those registers onto the stack before it overwrites them.
So the typical life of a value on such platforms is this:
Function a writes it into a register (r31) that may not be changed by function calls.
Function a copies the value into a register that is used for register passing (r3). Both copies reside in registers.
Function a calls function b.
Function b needs to call function c, after which call it still needs the value. So it takes a number of registers and saves them on the stack (including register r31 that originally held our value). Now there are three copies of the value: two in registers and one on the stack.
Function b copies the value into its old register (r3 -> r31), not knowing that it was there already. It calls function c. After this call, there is still one saved copy on the stack and one in register r31.
Function b does whatever it needs to do with our value. Finally, it restores the registers which it was not supposed to modify by loading their old value from the stack. From Function b's perspective, this destroys its working copy of the value in register r31, however, we still have one copy of the value in a register and one on the stack.
Function b returns, destroying its stack allocation, the stack copy of the value fades into oblivience. Only the original copy of the value within function a remains where it should be: in register r31.
Even though this approach seems complicated, it entails significantly fewer stack memory accesses than the X86-approach. Especially leaf routines that do not need to call any other functions, do not need to access the stack at all.
From http://en.wikipedia.org/wiki/Stack_pointer#Structure
I am wondering why the return address for a function is placed above the parameters for that function?
It makes more sense to have Return Address pushed onto the stack before the Parameters for Drawline because the parameters are not required any more when the Return Address is popped for returning back to the calling function.
What are the reasons for preferring the implementation shown in diagram above?
The return address is usually pushed via the call machine command, [which in the native language's instruction set] while the parameters and variables are pushed with several machine commands - which the compiler creates.
Thus, the return address is the last thing pushed by the caller, and before anything [local variables] pushed by the callee.
The parameters are all pushed before the return address, because the jump to the actual function and the insertion of the return address to the stack is done in the same machine command.
Also, another reason is - the caller is the one allocating space on stack for the parameters - It [the caller] should also be the one who cleans it up.
The reason is simple: The function arguments are pushed onto the stack by the calling function (which is the only one which can do it because only it has the necessary information; after all the whole point of doing so is to pass that information to the called function). The return address is pushed to the stack by the function call mechanism. The function is called after the calling function has set up the parameters, because after the call it's the called function which is executed, not the calling one.
OK, so now you could argue that the calling function could put the parameters beyond the currently used stack, and the called function could then just adjust the stack pointer accordingly. But that would not work out well because at any time there could be an interrupt or a signal, which would push the current state onto the stack in order to restore later (I wouldn't be surprised if a task switch did so, too). But if you set up the parameters beyond the current stack, those asynchronous events would overwrite it, and since you cannot predict when they will happen, you cannot avoid that (beyond disabling, which may have other drawbacks or even be impossible, in the case of task switch). Basically, everything beyond the current stack has to be considered volatile.
Also note that this is independent of the question of who cleans up the parameters. In principle, the called function could call call destructors of the arguments even if physically they lie in the caller's stack frame. Also, many processors (including the x86) have instructions which automatically pop extra space above the return address on return (for example, Pascal compilers usually did that because in Pascal you don't have any cleanup beyond returning memory, and at least fr the processors of the time, it was more efficient to clean up with that processor instruction (I have no idea if that is still true for modern processors). However C didn't use that mechanism due to variable-length argument lists: For those, the mechanism wasn't applicable because you'd need to know at compile time how much extra space to release, and K&R C did not require to forward-declare variadic functions (C89 does, but few if any compilers take advantage of that, due to compatibility with old code), so there was no way for the calling function to know whether to clean up the arguments unless it had to do that always.
I'm reading Thinking in C++ (vol. 2):
Whenever a function is called,
information about that function is
pushed onto the runtime stack in an
activation record instance (ARI), also
called a stack frame. A typical stack
frame contains (1) the address of the
calling function (so execution can
return to it), (2) a pointer to the ARI of
the function’s static parent (the
scope that lexically contains the
called function, so variables global
to the function can be accessed), and
(3) a pointer to the function that called
it (its dynamic parent). The path that
logically results from repetitively
following the dynamic parent links is
the dynamic chain, or call chain
I'm unable to comprehend what the author means as function's static and dynamic parent. Also am not able to differentiate between item 1, 2 or 3. They all seem to be the same. Can someone please explain this passage to me?
I think this statement is not about C++ but general structure of stack frame.
1) is return address - address of instruction after call in main function. when return is performed it will be poped from stack and execution will go to that point (valid for c++)
2) and 3) are valid for languages that allow nested functions. (Function declared inside function) such functions may have access to parent's variables, so they have link (static link) to parent's stack frame and dynamic link is for this functions to be able call themselves recursively
This all sounds very odd to me. Static frame pointers are normally used in languages with lexical scope, such as functional languages, and the pascal family with their nested functions. Globals are bound once either at compile time or runtime, and shouldn't need frame pointers. (1) is valid, but (2) doesn't exist in C++, AFAIK.
I suspect that (3) was meant to refer to the parent frame pointer. Call stacks are usually setup as linked lists so that debuggers and related tools can walk them without requiring deep knowledge of the program.
I would like to be able to determine if a pointer is on the stack or not at runtime for a number of reasons. Like if I pass it into a function call, I can determine whether I need to clone it or not. or whether I need to delete it.
In Microsft C (VC 6,7,8) is there a way to bounds check a pointer to see if it in on the stack or not? I am only concerned with determining this on the thread that owns the stack the object was placed on.
something like
static const int __stack_size
and __stack_top
????
Thanks!
Knowing whether an object is on the stack or heap isn't going to tell you whether it should be cloned or deleted by the called function. After all, you can clone either type, and while you shouldn't try to delete a stack-allocated function you shouldn't try to delete all heap pointers either.
Having a function that will make some arcane check to see whether it should delete a passed pointer or not is going to cause confusion down the line. You don't want a situation where you may or may not be able to refer to fields in an object you passed, depending on context. Nor do you want to risk a mistake that will result in trying to free a stack object.
There isn't any standard way to tell what a pointer points to, and any nonstandard way is likely to break. You can't count on stack contiguity, particularly in multithreaded applications (and somebody could easily add a thread to an application without realizing the consequences).
The only safe ways are to have a calling convention that the called function will or will not delete a passed object, or to pass some sort of smart pointer. Anything else is asking for trouble.
Interesting question.
Here's an idea on how to determine it, but not a function call.
Create a dummy variable at the very start of your application on the stack.
Create a variable on the stack in a function isOnStack( void *ptr )
Check to see that the 'ptr' is between the dummy variable and the local variable.
Remember that the stack is contiguous for a given thread. I'm not sure what would happen when you started checking from one thread to another for this information.
If it's not in the stack, then it must be on the heap.
I do not know any method to determine where an object was allocated.
I see this kind of behaviour should be avoided. Such things should imho be solved by contract between user and library developer. State these things in the documentation! If unsure copy the object (which requires a copy constructor and saves you from trying to copy uncopyable objects).
You can also use smart pointers from Boost. If unsure when an object is now longer needed, pass it as a shared pointer.
Doing this depends on the calling convention of the function. Some calling conventions place arguments in registers, others place them in memory after the head of the stack. Each one is a different agreement between the caller/callee. So at any function boundary in the stack a different convention could have been used. This forces you to track the calling convention used at every level.
For example, in fastcall, one or more arguments can be passed via registers.
See MSDN for more. This would mess up any scheme to figure out if an address exists within a certain range. In MS's thiscall, the this pointer is passed via registers. The &this would not resolve to somewhere between a range of values between the begin and end of the stack.
Bottom line, research calling conventions, it specifies how stack memory will be laid out. Here is a good tutorial
Note this is very platform specific!
This is very platform specific, and IMO suitable only for debug build diagnostics. What you'd need to do (on WIntel) is this:
When a thread is created, create a stack variable, and store its address in a global (threadid, stack base address) map.
IsOnStack needs to create its own local variable, and check if the pointer passed is between the stack base and the address in the current stack frame.
This will not tell you anything abotu variables within other threads. Stack addresses decrease, so the base address is higher than the current address.
As a portable solution, I'd pass a boost::shared_ptr, which can be associated with a deleter. (In boost, this is not a template parameter, so it doesn't "infect" the function consuming the pointer).
you can create an "unmanaged" pointer like this:
inline void boost_null_deleter(void *) {}
template <typename T> inline
boost::shared_ptr<T> unmanaged_ptr(T * x)
{
return boost::shared_ptr<T>(x, ::boost_null_deleter);
}
and call your function like this
Foo local = { ... };
FooPtr heapy(new Foo);
FunnyFunc(unmanaged_ptr(&local));
FunnyFunc(heapy);
I've wanted such a feature in C++ for a while now, but nothing good really exists. The best you can hope for is to document that you expect to be passed an object that lives on the heap, and then to establish an idiom in the code so that everyone working on the code base will know to pass heap allocated objects to your code. Using something like auto_ptr or boost::shared_ptr is a good idiom for this kind of requirement.
Well, I agree there is probably a better way of doing what you're trying to do. But it's an interesting question anyway. So for discussion's sake...
First, there is no way of doing this is portable C or C++. You have to drop to assembly, using at least a asm{ } block.
Secondly, I wouldn't use this in production code. But for VC++/x86 you can find out if a variable is on your stack by check that it's address is between the values of ESP and EBP registers.
Your ESP ( Extended Stack Pointer, the low value ) holds the top of your stack and the EBP ( Extended Base Pointer ) usually the bottom. Here's the Structure of the Call Stack on x86.
Calling convention will affect function parameters mainly, and how the return address is handled, etc. So it doesn't relate to your stack much. Not for your case anyway.
What throws things off are compiler optimizations. Your compiler may leave out the frame pointer ( EBP ). This is the -Oy flag in VC++. So instead of using the EBP as the base pointer you can use the address of function parameters, if you have any. Since those a bit higher up on the stack.
But what if that variable you're testing is on your caller's stack? Or a caller's stack several generations above you? Well you can walk the entire call stack, but you can see how this can get very ugly ( as if it isn't already :-) )
Since you're living dangerously, another compiler flag that may interest you is -
Gh flag. With that flag and a suitable _penter hook function, you can setup these calculations for the functions or files or modules, etc. easily. But please don't do this unless you'd just like to see how things work.
Figuring out what's on the heap is even worse....
On some platforms, the stack can be split by the run-time system. That is, instead of getting a (no pun intended) stack overflow, the system automatically grabs some more stack space. Of course, the new stack space is usually not contiguous with the old stack space.
It's therefore really not safe to depend on whether something is on the stack.
The use of auto_ptr generally eliminates the need for this kind of thing, and is way cooler besides.
The MSVC Windows compiler specific answer. This is of course specific to the thread the object is in. It's a pretty bad idea to pass any auto-stack item into any thread other than the one whos stack it is on so I'm not worried about that :)
bool __isOnStack(const void *ptr)
{
// FS:[0x04] 4 Win9x and NT Top of
stack // FS:[0x08] 4 Win9x and
NT Current bottom of stack
const char *sTop; const char
*sBot;
__asm {
mov EAX, FS:[04h]
mov [sTop], EAX
mov EAX, FS:[08h]
mov [sBot], EAX
}
return( sTop > ((const char *)ptr) && ((const char *)ptr) > sBot);
}