[PATCH] D140279: Adds support for GOT relocations to i386/ELF backend

[Kshitij Jain via Phabricator via llvm-commits]

jain98 added inline comments.


================
Comment at: llvm/test/ExecutionEngine/JITLink/i386/ELF_external_to_absolute_conversion.s:27-31
+        addl    $_GLOBAL_OFFSET_TABLE_+(.Ltmp0-.L0$pb), %eax
+        movl    $0, -4(%ebp)
+        movl    a at GOTOFF(%eax), %eax
+        addl    $4, %esp
+        popl    %ebp
----------------
lhames wrote:
> This sequence is trying to access the non-existent GOT-entry, which is why it crashes at runtime.
> 
> I think the assembly can be reduced to the i386 equivalent of the x86-64 sequence:
> ```
>         .text
>         .globl  main                            
>         .p2align        4, 0x90
>         .type   main, at function
> main:                    
> .L0$pb:
>         movl    $_GLOBAL_OFFSET_TABLE_-.L0$pb, %eax
>         movl    $foo at GOTOFF, %eax
>         xorl    %eax, %eax
>         retl
>         .size   main, .-main
> ```
> The '$' symbol at the start of the expression means that we're treating the result of the expression as an immediate, not an address to be loaded from. The immediate values that we move into `%eax` will be zeros, but since `%eax` isn't used anyway we can disregard that.
> This sequence is trying to access the non-existent GOT-entry, which is why it crashes at runtime.

I didn't quite get that. I //think//, you're referring to this instruction -
```
movl    a at GOTOFF(%eax), %eax
```
I thought this instruction was using `a`'s offset from the GOT symbol - not accessing any GOT entry? Could you point to the specific instruction that you were referring to in your comment?

I do think I understand why the seg fault might be happening though. Essentially `a at GOTOFF(%eax)` ends up being `a at GOTOFF(0x00000000)`? Which is likely out of the JITLink process' memory. If that is indeed the case, I have another question. The assembly that I used from the test was actually generated by Clang. Is it just that Clang uses a different linker that can actually handle the code that it's producing without seg-faulting?


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D140279/new/

https://reviews.llvm.org/D140279