Support R_ARM_REL32 and R_ARM_GOT_PREL in RuntimeDyldELF (SR-387)

[Lang Hames via llvm-commits]

No worries. :)

Thanks again for the patch!

- Lang.

On Thu, Aug 18, 2016 at 6:29 PM, William Dillon <william at housedillon.com>
wrote:

> 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> 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>
>> 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> 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> 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
>> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-commits
>>
>>
>> _______________________________________________
>> llvm-commits mailing list
>> llvm-commits at lists.llvm.org
>> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-commits
>>
>>
>>
>>
>> _______________________________________________
>> llvm-commits mailing list
>> llvm-commits at lists.llvm.org
>> 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/16c16624/attachment.html>