enter image description here

I'm new to gbd. I've wrote a simple program which will print hello world 10 times(I've listed the program in the screenshot). Then I've displayed the assembly language and set the break point to main and after running the program untill main, I've displayed the content of the rip register.

Now the confusion is, in the assembly code, the memory addresses are 0000...and then some number, but in the rip register the addresses are 55555...and then some number. For example in the line 4, containing mov instruction, the adderss is 0x000000000000113d and in the rip register the address is 0x55555555513d. I'm assuming those two addresses are same based on the common ending (13d), although not sure. But the previous digits are different. Why?

  • I assume that it's because the real memory address is calculated at run-time so the sum of the starting address (which your s.o allocates when you load it in your memory) plus the offset gives the real address location. So when you run a program, the memory address could change. Those 0x000 etc are initialized registers but the real address will be known only at run time.
    – Virgula
    Aug 30, 2020 at 14:39
  • @Virgula Ok I see..and what is s.o? Aug 30, 2020 at 14:56
  • sorry I miss clicked. it meant to be o.s which stands for the operating system. anyway, I think this is an offtopic question and your question is about how memory handles the processes and the answer it is not short and easy since there are many methods used by different types of o.s to handle the memory.
    – Virgula
    Aug 30, 2020 at 15:01
  • The value that does not change (113d) is the offset and it's the only part of the address which does not change. It is useful to reach the correct address in the main memory once the base address where the process is allocated has been calculated.
    – Virgula
    Aug 30, 2020 at 15:11
  • If you want to try to see static address space and understand better it, try to change and poke around with the value in proc/sys/kernel/randomize_va_space (change it to 0 with root permission). At runtime, the addresses will be always the same since now but the assembler could still show the initialized value to 000.
    – Virgula
    Aug 30, 2020 at 17:56

1 Answer 1


This is because your program was compiled as a position independant executable (PIE). Instead of the addresses being hardcoded into the binary, they are only stored as offsets from 0, which explains how you are seeing addresses such as 0x000000000000113d. At runtime, a randomized base address is generated, and all sections of the executable will exist at offsets from that base.

When you are running disassemble main, gdb is disassembling the executable itself without taking into account the runtime addresses. In fact, there are no runtime addresses yet since you haven't started the binary. If you want to see the actual addresses, you will need to try to disassemble again after execution has started.

  • The base address it is not randomized but it's calculated based on some factors just like space that the process requires, the other already allocated memory addresses for other processes etc.. Algorithms for memory handling helps to calculate this value.
    – Virgula
    Aug 30, 2020 at 15:07
  • @Virgula where are you getting that? If it's not random, it's certainly not predictable either. Other processes don't share the same virtual address space, so I'm not sure what you mean. Aug 30, 2020 at 19:54
  • That's because of how virtual memory works but not a feature of the main memory itself. Addresses are certainly calculated not 100% randomized or the main memory will occur in leaks and fragment problems for sure.
    – Virgula
    Aug 31, 2020 at 6:56
  • I'm in accord with you that the user which cannot pre-calculate the address/es that will be assigned to the process because he doesn't know the memory status at that time.
    – Virgula
    Aug 31, 2020 at 7:06

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .