Why can nasm assembly with unqualified references to _GLOBAL_OFFSET_TABLE_ apparently be assembled and linked as PIC?

Question

Why can I assemble and link get_got.asm as position-independent code when it contains a reference to the absolute address of its GOT?

get_got.asm

extern _GLOBAL_OFFSET_TABLE_

section .text
global get_got
get_got:
        mov     rax, _GLOBAL_OFFSET_TABLE_
        ret

main.c

#include <stdio.h>

void* get_got(void);

int main(int argc, char* argv[]) {
    printf("%p\n", get_got());
}

assembling, compiling, linking, running:

nasm -felf64 -o get_got.o get_got.asm
gcc -fPIC -shared -o get_got.so get_got.o
gcc -Wl,-rpath=\$ORIGIN -o main main.c get_got.so
./main
0x148ba1cba000

What's going on here? It looks to me like get_got.so somehow has a baked-in absolute address for a GOT that won't have a known address until runtime. Disassembling get_got.so shows that the mov does in fact contain an immediate (0x201000). Obviously I have a major misunderstanding of something. I expected this to cause nasm to generate a relocation that the linker would choke on.

Note that for PIC you are allowed to have absolute references to data. Now, try with `-pie` instead. Then you should see a dynamic relocation entry in the final binary output. EDIT: oh you did a `.so` ... well then you should see the relocation in there. — Jester, Dec 18 '17 at 17:13
Of course you don't typically need `_GLOBAL_OFFSET_TABLE_` in 64 bit code, you just use rip-relative addressing with `GOTPCREL`. — Jester, Dec 18 '17 at 17:25
You still need a GOT for global variables imported from shared libraries, no? — zneak, Dec 18 '17 at 17:27
You will have a GOT, but you address it rip-relative fashion, e.g. you can write `mov eax, [rel foo wrt ..got]`. — Jester, Dec 18 '17 at 17:29

Peter Cordes · Accepted Answer · 2017-12-18T18:05:42.810

I built your code and a modified version using lea rax, [rel _GLOBAL_OFFSET_TABLE_].

I diffed the readelf -a output. There's a lot of noise from different addresses, though.
readelf -a get_got.so | diff -u - <(readelf -a get_got_rel.so) | less

The most interesting difference is:

--- readelf -a get_got.so
+++ readelf -a get_got_rel.so
....

-Dynamic section at offset 0xe40 contains 22 entries:
+Dynamic section at offset 0xe50 contains 21 entries:
...

- 0x0000000000000016 (TEXTREL)            0x0
  0x000000006ffffffe (VERNEED)            0x3b0
  0x000000006fffffff (VERNEEDNUM)         1
  0x000000006ffffff0 (VERSYM)             0x398
- 0x000000006ffffff9 (RELACOUNT)          4
+ 0x000000006ffffff9 (RELACOUNT)          3

So the absolute version has a text relocation. I didn't know Linux / ELF dynamic linking could apply fixups after mapping shared libraries. But apparently it can. (It's better not to, because it dirties the memory page so it's no longer just backed by the file on disk.)

But I checked with GDB, and that's what's going on: set a breakpoint in get_got and run it:

(gdb) disas
Dump of assembler code for function get_got:
=> 0x00007f9e77b235b0 <+0>:     movabs rax,0x7f9e77d24000
   0x00007f9e77b235ba <+10>:    ret

objdump -dRC -Mintel get_got.so: (note line wrapping without -w):

00000000000005b0 <get_got>:
 5b0:   48 b8 00 10 20 00 00    movabs rax,0x201000
 5b7:   00 00 00 
                        5b2: R_X86_64_RELATIVE  *ABS*+0x201000
 5ba:   c3                      ret

Thanks @Jester for the -R tip; I normally use objdump -dr ..., not -R, and lower-case r doesn't print any relocations for the .so.
On get_got.o, -r shows movabs rax,0x0 2: R_X86_64_64 _GLOBAL_OFFSET_TABLE_.

gcc -nostdlib -pie will link 64-bit absolute relocations into PIE executables as well. (A PIE executable is an ELF shared object).

What isn't allowed in PIC / PIE are 32-bit absolute relocations: 32-bit absolute addresses no longer allowed in x86-64 Linux?. You get a linker error. Addressing modes like array[rcx*4] aren't usable in PIC/PIE code, you need a separate instruction to get the address into a register.

lea rdi, [rel array] is a much better choice than a 64-bit immediate absolute, because it's smaller and more friendly to the uop cache, and doesn't require a fixup when loading.

That answers the question but certainly raises questions in my mind about the implications of a fixup like this. Thanks. — Praxeolitic, Dec 18 '17 at 17:40
That's why you avoid it, as I said. I believe macos doesn't even allow it. — Jester, Dec 18 '17 at 17:40
@Jester: thanks, I forgot there was a `-R` separate from the `-r` I usually use in my `alias disas='objdump -drwC -Mintel'` — Peter Cordes, Dec 18 '17 at 18:06

Why can nasm assembly with unqualified references to _GLOBAL_OFFSET_TABLE_ apparently be assembled and linked as PIC?

1 Answers1