globals

[ygfperson]

every function starts and ends with some appropriate stack saving commands (at least in the standard calls). the function receives variables and declares local variables in the stack.

my question is, where do global variables go? is space for it saved in the stack at the beginning? or does it go somewhere else? what about const char* strings?

[Prelude]

Global variables are kept in a different segment than the stack. This segment is usually, but not always, referred to as the Data segment. An a.out file is usually described like so (The lowest item being the lowest memory address):

Magic number
Stack Segment - Data local to functions.
BSS Segment size - Uninitialized data.
Data Segment - Global and static variables
Text Segment - Machine instructions

-Prelude

[Sayeh]

Yes, in fact, let's alter this slightly and relable it-- it'll make more sense (We'll ignore 'Magic Number' that's not germane to our context):

This is your heap zone.

STACK
--------
This is your stack. Highest location in heap, grows down towards Data) It "grows" as functions are called because they leave their variables "on the stack". When the function ends, these variables are removed (stackframe space is reclaimed) and the stack _shrinks_. If the space between the Data segment and the stack isn't large enough to handle this changing "growth", the stack can grow into the data and code segments, corrupting the values there.

RAW
------
Unused RAM between Stack and Data. Allocations occur here, otherwise the are taken from system ram.

DATA
-------
Global and static variables, constants, text strings.

CODE (more accurate than 'text')
-------
Machine instructions. This is where your code lives, preceded by a short stub and jumptable section. The start of this is the lowest address in your heap zone.

[Fordy]

>>what about const char* strings?

I can only speak for windows and what I have seen from peeking into my exes, but most compilers/linkers would put global const char*s into a read only section. Microsoft's Link.exe program (used with MSVC++) labels this section ".idata" by default, and when it is loaded it is mapped into a piece of memory marked readonly.....So at runtime your code can access the contents of this memory, but cant alter them (your compiler will most likely have kicked out any such nonsence before linking anyway)...

Funny though....if you declare a const int globally, you may find your compiler simple absorbing the value of the int into the opcode itself....

ala

const int foo = 0xFFFFFFFF;//global

//.....other code

int bar = foo;//disassembly - mov dword ptr [ebp-4],0FFFFFFFFh

So effectively, foo didnt exist in memory!

I tried this with declaring foo in the main function and it simply created it as a local variable.....pushed it on the stack....and relied on the checking at compile time to make sure that no piece of code tried to alter that location.....