Why is a function executed from the same memory address each time?

Question

I'm disassembling an executable:

(gdb) disas main
Dump of assembler code for function main:
0x004012d0 <main+0>:    push   %ebp
0x004012d1 <main+1>:    mov    %esp,%ebp
...

Each time the memory address is the same:0x004012d0.

Isn't the memory address to be dynamically assigned by the OS?

UPDATE

Now I see it's virtual space,and it can be randomized on some platforms.

Can someone post a gdb dump that changes ?

Answer 1

Why would the OS pick a different address?

When the OS execs a process, it loads an executable file into a virtual memory space. Along the way, it will resolve any relative and/or symbolic references. Assuming that you have the same executable, and the same shared libraries, and start it the same way that you did the previous time, it would be very strange for the OS to decide to load the executable in a different way.

Answer 2

That is a virtual address. The physical address is known to the OS, but each process has its own virtual address space. A relocatable image is likely to get the same mapping everytime, especially the main executable. But it is not guaranteed. An example is DLLs. DLLs may load in different order, resulting in different virtual addresses between runs, because as DLL 1 is loaded, then DLL 2 cannot be loaded into that virtualaddress and must get its own address.

Answer 3

Yes and no. The physical memory is allocated by the OS, and only the OS is aware of where your program is in physical RAM. Your program only sees the virtual address, which will always be the same if everything is loaded in the same order.

Answer 4

It depends on the OS. Most of the time the address of the binary stays the same. This is important for exploiting memory manipulation bugs, such as buffer overflows. The address of linked libraries under Linux will always be different due to ASLR. Under Windows Vista and Windows 7 the binary's virtual memory space is also randomized each time it is executed, so the function address will be different for each run.

Answer 5

Executable relocation

Some executables are set so that they are always loaded at the same address. Some are set so that they are "relocatable". The option controlling this in Visual Studio linker is called /FIXED. Even such executables are most often loaded at preferred address. Newer OS (Win7, Vista) randomize the loading address for some executables to improve security (attacking process loaded at unknown address is harder) - this is called ASLR. Note: Even executable marked as /FIXED:NO is not assumed to be suitable for ASLR. Developer needs to allow ASLR explicitly for the executable.

Virtual address space

Note: It is important to understand the process owns the whole address space. Multiple processes have each address space of their own, therefore if you launch the same executable multiple times, there is no reason why it could not be loaded at the same address every time.

Answer 6

It depends on the operating systems. In most modern operating systems with virtual memory there is no need for executable code to be relocatable, but in older operating systems, and in some specialised operating systems (e.g. real-time, embedded) code overlays may be used in conjunction with position-independent code and jump tables. In this case it's possible for a function's address to change, e.g. if its code segment is swapped out and then swapped back in at a different address.

Answer 7

I think the problem here (at least on Linux) might be gdb trying to help out, from the docs:

set disable-randomization

set disable-randomization on

This option (enabled by default in gdb) will turn off the native randomization of the virtual address space of the started program. This option is useful for multiple debugging sessions to make the execution better reproducible and memory addresses reusable across debugging sessions.

This feature is implemented only on gnu/Linux. You can get the same behavior using

         (gdb) set exec-wrapper setarch `uname -m` -R

http://sourceware.org/gdb/current/onlinedocs/gdb/Starting.html

UPDATE: I've now checked this and it does seem to be the case for me (running Linux 2.6.28). Compile a simple Hello World program and start gdb with no command-line args (we don't want to load the program before overriding the disable-randomization setting) and then enter:

(gdb) set disable-randomization off
(gdb) file ./a.out
(gdb) break main
(gdb) run
(gdb) disas printf

The address of printf is different each time the program is run.