Does a linker generate absolute virtual addresses when linking

7
votes

Assume a simple hello world in C, compiled using gcc -c to an object file and disassembled using objdump will looks like this:

_main:
       0:   55  pushq   %rbp
       1:   48 89 e5    movq    %rsp, %rbp
       4:   c7 45 fc 00 00 00 00    movl    $0, -4(%rbp)
       b:   c7 45 f8 05 00 00 00    movl    $5, -8(%rbp)
      12:   8b 05 00 00 00 00   movl    (%rip), %eax

As you can see the memory addresses are 0, 1, 4, .. and so on. They are not actual addresses.

Linking the object file and disassembling it looks like this:

_main:
100000f90:  55  pushq   %rbp
100000f91:  48 89 e5    movq    %rsp, %rbp
100000f94:  c7 45 fc 00 00 00 00    movl    $0, -4(%rbp)
100000f9b:  c7 45 f8 05 00 00 00    movl    $5, -8(%rbp)
100000fa2:  8b 05 58 00 00 00   movl    88(%rip), %eax

My question is, is 100000f90 an actual address of a byte of virtual memory or is it an offset?

How can the linker give an actual address prior to execution? What if that memory address isn't available when executing? What if I execute it on another machine with much less memory (maybe paging kicks in here).

Is't it the job of the loader to assign actual addresses?

Is the linker generating actual addresses for he final executable file?

2
macosassemblylinkerexecutablevirtual-memory
It's virtual memory. It is always available on a given architecture, doesn't matter how much physical memory you have. There may be special cases, e.g. if you tweak your 32 bit OS to use a 3G/1G split then you could theoretically put your stuff above 2G which a normal OS wouldn't be able to load. Also x86-64 comes with varying VM sizes but there are known safe ranges. - Jester
Yes, in a position-dependent executable, static code/data addresses are link-time constants. See 32-bit absolute addresses no longer allowed in x86-64 Linux? for more about PIE executables where that's not the case, requiring position-independent code that uses RIP-relative addressing even for putting an address into a register, instead of 5-byte mov $symbol, %edi. - Peter Cordes
This is OS X, right? The linker chose a base address outside the low 2GiB of virtual address space, but it looks like there is a default load address. - Peter Cordes
the linker links to the addresses it is told. by you directly or indirectly. If using a non-cross compiler for your computer, and the compiler works then that is the address space for your executable, which is likely virtual since this is an application to run on an operating system yes? linkers are not smart, like compilers, they do what you tel them, they are very dumb. - old_timer
It may be enlightening to apply otool -lV to your executable. That will show the linker load commands. Code is in the __TEXT segment. The load commands specify a "load (virtual) address" for the segments. That can be influenced by link command options or left to linker defaults. For position-independent executables, the loader can load to a different address; otherwise, it will load to the specified address. - Ken Thomases

2 Answers

8
votes

(The following answers assume that the linker is not creating a position-independent executable.)

My question is, is 100000f90 an actual address of a byte of virtual memory or is it an offset?

It's the actual virtual address. Strictly speaking, it is the offset from the base of the code segment, but since modern operating systems always set the base of the code segment to 0, it is effectively the actual virtual address.

How can the linker give an actual address prior to execution? What if that memory address isn't available when executing? What if I execute it on another machine with much less memory (maybe paging kicks in here).

Each process gets its own separate virtual address space. Because it is virtual memory, the amount of physical memory in the machine doesn't matter. Paging is the process by which virtual addresses get mapped to physical address.

Isn't it the job of the loader to assign actual addresses?

Yes, when creating a process, the operating system loader allocates physical page frames for the process and maps the pages into the process's virtual address space. But the virtual addresses are those assigned by the linker.

-1
votes

Does a linker generate absolute virtual addresses when linking

It depends upon the linker setting and the input source. For general programming, linkers usually strive to create position independent code.

My question is, is 100000f90 an actual address of a byte of virtual memory or is it an offset?

It is most likely an offset.

How can the linker give an actual address prior to execution?

Think about the loader for an operating system. It expects things to be in specific address locations. Any decent linker will allow the programmer to specify absolute addresses some way.

What if that memory address isn't available when executing? What if I execute it on another machine with much less memory (maybe paging kicks in here).

That's the problem with position-dependent code.

Is't it the job of the loader to assign actual addresses?

The job of the loader is to follow the instructions given to it in the executable file. In creating the executable, the linker can specify addresses or defer to the loader in some cases.