just a currious question, how does a computer know where a global is stored

[*DEAD*]

Hi, this is just something that passed my mind and has been bothering me since.
if something is declared
int i
you can find out its address by
&i
but wheres that address stored
&&i
&&&i
and so on. where does it stop. how does the cpu know where i is.

[MacGyver]

There's no such thing. The address of a variable isn't really "stored" anywhere per se. It's actually always used in the code when you access i. That's what's really in the compiled code. There's no reference to the variable by name (speaking in general about variables).

[*DEAD*]

yes but if i say i want a cookie, you can say its in the cupboard, but wheres the cupboard?

[Salem]

> if something is declared
> int i
For a global, it is the linker / program loader which assigns this variable to an actual address in memory (say 0x1234).

So when you do something like
i = 0;
The code which actually gets executed is something like
mov 0,0x1234

It's basically the same for local variables, except they're all accessed as an offset relative to a stack pointer.

[MacGyver]

Salem beat me to it, but I'll post the example anyway:

demoaddress.c:

#include <stdio.h>

int g_i = 1337;

int main(void)
{
	int i;
	
	i = 5;
	g_i = 10;
	
	printf("i = %d\n",i);
	printf("g_i = %d\n",g_i);
	
	return 0;
}

Having MinGW spit out the assembly... demoaddress.s:

        .file   "demoaddress.c"
.globl _g_i
        .data
        .align 4
_g_i:
        .long   1337
        .def    ___main;        .scl    2;      .type   32;     .endef
        .section .rdata,"dr"
LC0:
        .ascii "i = %d\12\0"
LC1:
        .ascii "g_i = %d\12\0"
        .text
        .p2align 4,,15
.globl _main
        .def    _main;  .scl    2;      .type   32;     .endef
_main:
        pushl   %ebp
        movl    $16, %eax
        movl    %esp, %ebp
        subl    $8, %esp
        andl    $-16, %esp
        call    __alloca
        call    ___main
        movl    $LC0, (%esp)
        movl    $10, %edx
        movl    $5, %eax
        movl    %edx, _g_i
        movl    %eax, 4(%esp)
        call    _printf
        movl    $LC1, (%esp)
        movl    _g_i, %eax
        movl    %eax, 4(%esp)
        call    _printf
        leave
        xorl    %eax, %eax
        ret
        .def    _printf;        .scl    3;      .type   32;     .endef

i is never mentioned in the assembly code because it's a local variable and on the stack. That's how the compiler knows the address of that one.

For the global variable g_i, you can see it's referenced by name. By the time it gets to the exe, however, all references to g_i are no longer by name. Because it's global, it's put right into the application itself, and the address assigned it by the linker is set at that time.

Consider this line in C:

g_i = 10;

This is how GCC translated that into assembly:

movl    $10, %edx
...
movl    %edx, _g_i

Salem's explanation is the key here to understanding this. When the linker goes through the assembly code to make an exe, it'll change the assembly reference to _g_i to something like 0x40302092 (I chose a random address, but the process is not random.) or as Salem suggested, 0x1234. Date will be moved to and from the spot the address refers to. When you write &g_i in C code, it'll just result in 0x40302092 (or whatever address the linker set it to). Doing &&g_i doesn't make much sense. You won't get anything meaningful.

[CornedBee]

Not quite. In modern executables, the linker will just assign an offset to the address. It is the exe loader's job to walk through the program and replace all these offsets by the real memory location, by adding the offset to the base address of the executable.