OSDev.org

Say I have code such as the following:If we just ignore for now the fact that foo would probably be discarded during optimisation, where in memory is foo allocated? Is it different if I doorBasically I need to know, in each case, where in memory GCC will put the variable? What about arrays? I know that parameters and return values are transferred on the stack, but I seem to think that variables are allocated in some pre-determined region of memory (the "heap") and I don't know how to tell GCC where that heap must be. This also doesn't make sense when I compile the code as position-independent, because the code cannot be position-independent if it still assumes that the heap is at a fixed address.

Local variables are stored at the stack (automatic storage), static and global variables are stored in static storage.

Local variables are allocated on the stack, globals end up in the data section. The heap is traditionally only for malloc()

You could also just have compiled it without optimisations.

There is a very simple way to answer questions like this. Examine the compiled code to see what it does.

Note that "parameters and return values are transferred on the stack" is not true for 64-bit code.

iansjack wrote:There is a very simple way to answer questions like this. Examine the compiled code to see what it does.

Note that "parameters and return values are transferred on the stack" is not true for 64-bit code.

1. I examined the compiled code, but that doesn't tell me conclusively that the compiler will behave the same way in all situations.

2. I am compiling, and discussing the compilation of, 32-bit code.

Local variables are allocated on the stack. Global uninitialized variables are allocated in the .bss section, which is not present in the file, instead it is allocated and zeroed by the loader.

onlyonemac wrote:1. I examined the compiled code, but that doesn't tell me conclusively that the compiler will behave the same way in all situations.

You can rest assured that in such a fundamental matter the compiler will behave consistently.

I'm rather surprised that the wiki doesn't cover this; while it is more of a compiler implementation issue that an OS dev issue, it is certainly something that an OS dev should know ahead of time. I may add a page on general memory handling principles.

As an aside (and I expect you've already heard this a dozen times or more), don't ever declare main() as any type other than int in C or C++.

When the void type was introduced in the late 1980s, there were a few compilers *cough*turboc*cough* that misinterpreted the ANSI standard to imply that using void as a return type for main() was OK; what the standard actually said was that the return type was implementation-dependent, but that int was to be accepted if at all possible; i.e., only int was portable, and alternatives should only be used if the system absolutely could not handle an integer return value. Later versions of the standard removed this clause entirely, so with the newest C standards void main() is specifically deprecated.

In theory, the C Standard and the ABI are to be maintained, and that only really defines how functions are called and returned from. With sufficient optimisations and compilation options, it might store your data anywhere as long as it maintains semantics.

onlyonemac wrote:Basically I need to know, in each case, where in memory GCC will put the variable? What about arrays? I know that parameters and return values are transferred on the stack, but I seem to think that variables are allocated in some pre-determined region of memory (the "heap") and I don't know how to tell GCC where that heap must be. This also doesn't make sense when I compile the code as position-independent, because the code cannot be position-independent if it still assumes that the heap is at a fixed address.

I don't think it's possible to know. GCC is free to generate code as it likes as long as it follows the ABI. The compiler may place local variables in registers, move them around or optimise them out of existence.

The heap more or less belongs to the C library (and the OS). GCC don't really concern itself with it so doesn't need to know where it is.

External variables are placed in the data segment and the linker assigns addresses to them. I suppose whole program optimisation could remove or optimise away these variables as well.

You will be fighting with the compiler all the way while you do this.

Schol-R-LEA wrote:As an aside (and I expect you've already heard this a dozen times or more), don't ever declare main() as any type other than int in C or C++.

Why not? I normally use int for my main() function but in this case having main() return a value is just going to give me clutter to clean up in the calling function, as I don't want or need a return value from the entry point for my code module.

EDIT: Is it possible, then, to compile a module without a main() function? (i.e. to call main() something else more meaningful.)

If your entry point doesn't reference the main function, then yes. Since this is the OSDev.org forum, I assume you can define your own entry code.

Is it possible, then, to compile a module without a main() function? (i.e. to call main() something else more meaningful.)

It's possible to compile a module without any functions at all, let alone main(), if you so wish. The modules that you are producing, since you are using a flat format, are just a collection of binary numbers. How your OS chooses to interpret those numbers is up to you.

Several environments use an alternative to main() in executables.

Roman wrote:If your entry point doesn't reference the main function, then yes. Since this is the OSDev.org forum, I assume you can define your own entry code.

iansjack wrote:

Is it possible, then, to compile a module without a main() function? (i.e. to call main() something else more meaningful.)

It's possible to compile a module without any functions at all, let alone main(), if you so wish. The modules that you are producing, since you are using a flat format, are just a collection of binary numbers. How your OS chooses to interpret those numbers is up to you.

Several environments use an alternative to main() in executables.

Thanks both for the clarification.