[PATCH] Allow ARM ELF relocs to be applied twice

[Renato Golin]

Hi Tim,

Sorry, it's holiday today in UK...

So, I think the patch makes sense, but I have some comments.

First, you're re-defining the place-holder many times. I take it it's not
used on all cases, but often enough to maybe be commoned up and hope the
compiler does a good job?

Also, you're using the PRIVATE-0, which has no use AFAICT, but also no
comment on it about the expected behaviour on ELF.h. I'm not sure what's
the policy on enum reserved entries, but one way is to rename it to
something meaningful, another is to add a one-line comment on ELF.h about
its usage in the EE.

Apart from that, I think it looks good. But I'm no expert in the EE.

cheers,
--renato


On 27 May 2013 08:50, Tim Northover <t.p.northover at gmail.com> wrote:

> Ping?
>
> On Sat, May 25, 2013 at 9:16 AM, Tim Northover <t.p.northover at gmail.com>
> wrote:
> > Hi,
> >
> > This patch is designed to fix PR16013, which notes that ARM's MCJIT
> > relocation processing can't be reliably applied twice since each
> > iteration changes the state used by the next. It should allow remote
> > MCJIT to work reliably on ARM ELF.
> >
> > The bulk of the patch brings ARM in line with other targets (like
> > i386) in taking the .rel addends from the object-file as emitted
> > rather than the one being modified.
> >
> > However, there is an extra complication which I think deserves review.
> > The stubs created by the JIT need relocation, but don't actually have
> > any addend bits to take from the emitted object-file. This means that
> > none of the generic handling can work for them.
> >
> > There are two potential solutions to this:
> > 1. Use the R_ARM_PRIVATE_0 special relocation completely internally
> > within RuntimeDyldELF (see patch).
> > 2. Teach generic RuntimeDyld about the difference between .rel and
> > .rela relocations, so that it can handle object files emitted using
> > both styles. Then the stubs would become a .rela style R_ARM_ABS32
> > with addend 0.
> >
> > I decided that the second option was rather heavyweight since I can't
> > see LLVM ever actually emitting both .rel and .rela sections.
> >
> > OK to commit?
> >
> > Tim.
>
> _______________________________________________
> llvm-commits mailing list
> llvm-commits at cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20130527/a68427c5/attachment.html>