memory address - Why do the first digits of disassembled instructions in gdb not match the value in rip? Can anyone provide background?

Question

First time disassembling a program in a few months using GDB and on a new linux VM. Last time, when I disassembled a program, set a breakpoint, and ran, the value returned by "i r rip" would EXACTLY match the address of one of the program instructions.

This time, the value returned by "i r rip" == 0x5...54699 <main+15" while the assembly address shown for <+15> == "0x0...0699".

Is GDB now using relative addressing and zeroing the more significant (irrelevant?) address bits similar to what Wireshark does for sequence numbers?

This is my screen dump: Disassembled code and rip query

question from:https://stackoverflow.com/questions/65893945/why-do-the-first-digits-of-disassembled-instructions-in-gdb-not-match-the-value

Answer 1

You are looking at position-independent executable (PIE).

This executable is linked to load at address 0, and is relocated to 0x54... address on execution.

If you disas main before first running the binary, GDB will show the original linked-at addresses. If you do the same command after first run, GDB will show relocated (actual) addresses.

You can also link non-PIE binary with gcc t.c -no-pie. That binary will exhibit the behavior you expect: the output of disas main will not change between before and after first run, and the disassembly will match the actual value of rip at runtime.