Jump to content
  • Advertisement
Sign in to follow this  
Ben Bowen

Program Stacks and Uninitialized function data

This topic is 1927 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

Regarding the implementation of the C-programming language.

void Example()
{
ExStruct example;
LoadExStruct(example);
}

Will 'example' occupy the program data (i.e. generated machine code) before this function's scope is pushed onto the program stack during execution?

I am in fact using C++, but let's assume ExStruct is a raw struct without any constructors or the default is just ExStruct::ExStruct(){};

Edited by Reflexus

Share this post


Link to post
Share on other sites
Advertisement
I'm not sure what you're referring to by "generated machine code"; machine code does not contain data, but it can reference data that is allocated automatically as part of loading the binary. This typically occurs for static variables.
 
In your case, the object is not instantiated until the "ExStruct example;" line is executed. It shouldn't even exist when the function creates its stack frame - it's a separate and distinct event.

Share this post


Link to post
Share on other sites

Ok, just to be 100% certain, verify this:

 

void Example()
{
int bob = 5;
}

The value of 5 is loaded from the program data onto the stack, whereas

void Example()
{
int bob;
SetBob(&bob);
}

May load the value from elsewhere, but the fact that I've declared "int bob;" will not occupy a linked executable?

Once an executable is linked, will the value of 5 -- even it is referred to multiple times -- be associated with a single position within the executable?

Share this post


Link to post
Share on other sites


Once an executable is linked, will the value of 5 -- even it is referred to multiple times -- be associated with a single position within the executable?

 

Not necessarily. It can be duplicated, referenced, or even encoded inside the load/store instruction (on some CPU's), it's all up to the architecture. Remember that C doesn't really mandate anything with respect to the final machine code that ends up being generated. All that matters is that there exists some mapping between the machine architecture and the concepts used by the C language (a "stack", a "heap", a "program data section", and so on).

 

The fact that you've declared "int bob" does not really map to any well-defined equivalent in the executable code generated. Depending on your compiler, processor, operating system, all sorts of stuff, it might do absolutely nothing, increase register pressure, force the compiler to allocate 4 more bytes from the stack for this function (leading to a push/pop instruction pair or similar) or it might cause the executable to grow 200 terabytes in size if you're working on a futuristic computer where memory is near infinite.

 

It's really hard to predict what happens to the program when you do such and such change in the source code. Compilers are extremely clever these days. The best way to really know what's going on would be to get your compiler to output readable assembly code instead of translating it directly to executable machine code. If you're using gcc, the -S flag will do that for you.

Share this post


Link to post
Share on other sites

You may want to write some simple functions in VS, then disable all optimization and step through the assembly to see how the stack works. If you place a breakpoint at the start of the program, then open the memory view window and type in location EBP you should get a view of the stack. To see the disassembled code just r-click the code during debug and there should be an option for 'go to disassembly' or something like that. You can watch, instruction by instruction as it creates, uses and destroys the stack frames. You'll want to add EBP and ESP to your watchlist so you can see the register values that control the stack.

Share this post


Link to post
Share on other sites
Sign in to follow this  

  • Advertisement
×

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

We are the game development community.

Whether you are an indie, hobbyist, AAA developer, or just trying to learn, GameDev.net is the place for you to learn, share, and connect with the games industry. Learn more About Us or sign up!

Sign me up!