[PATCH v2] tidy the MCJIT tests now applyPermissions will invalidate cache

[Tim Northover]

Hi Andrew (etc),

I've been looking at this recently and hit a snag that probably needs
some design consensus to resolve.

> The thing that needs to change in RuntimeDyldELF to allow multiple
> relocations on ARM is to use Section.ObjAddress to read any values that need
> to be retrieved from the original object image.

The problem I've hit is that stubs get created for large branch
distances and these need to be relocated in some way. However, these
stubs only exist in the Section.Address space so when you offset the
incoming data from Section.ObjAddress you read garbage.

This only occurs on platforms with both .rel relocations and stubs of
course, of which ARM (& MIPS) seem to be the first.

I've got two potential solutions at the moment, a lightweight (hacky?)
one and a heavyweight (overengineered?) one.

1. We could comandeer one of ARM's private relocations for these stubs
in RuntimeDyld. They're essentially guaranteed never to be used
officially so we could make one behave "almost like R_ARM_ABS32 except
ignore the Placeholder". We could even put it completely out of the
r_type range so that could be reasonably platform-independent.

2. Implement enough support for both .rel and .rela sections in
RuntimeDyld so that it can handle us adding the stub relocations as a
.rela. In principle this is nicer if we anticipate LLVM ever wanting
to emit both .rel and .rela relocations for a single target (triple).
On the other hand it's more intrusive (probably means adding a field
to RelocationEntry and teaching both MachO and ELF how to use it
properly).

Anyone got any thoughts on the best approach?

Cheers.

Tim.