Support R_ARM_REL32 and R_ARM_GOT_PREL in RuntimeDyldELF (SR-387)

[William Dillon via llvm-commits]

Hi Lang,

That's great, thank you so much.  I'm glad you took a look because most of what you just said went over my head. :)

Cheers,
- Will

> On Aug 18, 2016, at 6:25 PM, Lang Hames <lhames at gmail.com> wrote:
> 
> Hi William,
> 
> Daniel told me you were still hoping to land this, so I took a stab at writing a test for it and discovered that, unfortunately, RuntimeDyldELF's GOT building mechanism (which uses a separate section for GOT entries) isn't compatible with RuntimeDyldChecker.
> 
> The proper solution to that is to fix RuntimeDyldELF's GOT handling (it's not safe to use a separate section in general, as it may be allocated out of range of a PC-rel GOT entry load), but that's non-trivial.
> 
> In the mean time, since this patch doesn't change any existing behavior I've committed in r279182.
> 
> Cheers,
> Lang.
> 
> 
> On Tue, Mar 22, 2016 at 1:05 PM, Lang Hames via llvm-commits <llvm-commits at lists.llvm.org <mailto:llvm-commits at lists.llvm.org>> wrote:
> Hi Michael, William,
> 
> William - thank you very much for this!
> 
> If possible, could you please add an ELF test case to llvm/test/ExecutionEngine/RuntimeDyld/ARM? There is an existing MachO test case there that may be of some help, though it does not contain any GOT relocation tests. From the x86-64 GOT test:
> 
> # Test PC-rel GOT relocation.
> # Verify both the contents of the GOT entry for y, and that the movq instruction
> # references the correct GOT entry address:
> # rtdyld-check: *{8}(stub_addr(test_x86-64.o, __text, y)) = y
> # rtdyld-check: decode_operand(insn3, 4) = stub_addr(test_x86-64.o, __text, y) - next_pc(insn3)
> insn3:
>         movq    y at GOTPCREL(%rip), %rax
> 
> The first test is reading the value of the stub (in this case GOT entry) for y and verifying that it contains the address of y.
> The second test is verifying that the PC-relative offset for the instruction is equal to the difference between the stub address and the next instruction.
> 
> Cheers,
> Lang.
> 
>> On Mar 22, 2016, at 12:58 PM, Michael Gottesman <mgottesman at apple.com <mailto:mgottesman at apple.com>> wrote:
>> 
>> I am not actually reviewing this, but just as a drive by: This is definitely going to need tests.
>> 
>>> On Mar 22, 2016, at 12:56 PM, Michael Gottesman via llvm-commits <llvm-commits at lists.llvm.org <mailto:llvm-commits at lists.llvm.org>> wrote:
>>> 
>>> Lang, can you take a look at this one?
>>> 
>>>> On Mar 22, 2016, at 10:59 AM, William Dillon via llvm-commits <llvm-commits at lists.llvm.org <mailto:llvm-commits at lists.llvm.org>> wrote:
>>>> 
>>>> <llvm.patch>This change supports the swift interpreter on armv7-based linux machines.  This is required for a number of tests and the package manager.
>>>> 
>>>> - Will_______________________________________________
>>>> llvm-commits mailing list
>>>> llvm-commits at lists.llvm.org <mailto:llvm-commits at lists.llvm.org>
>>>> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-commits <http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-commits>
>>> 
>>> _______________________________________________
>>> llvm-commits mailing list
>>> llvm-commits at lists.llvm.org <mailto:llvm-commits at lists.llvm.org>
>>> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-commits <http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-commits>
>> 
> 
> 
> _______________________________________________
> llvm-commits mailing list
> llvm-commits at lists.llvm.org <mailto:llvm-commits at lists.llvm.org>
> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-commits <http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-commits>
> 
> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20160818/22a5bf4c/attachment.html>