Commit Graph

3 Commits

Author SHA1 Message Date
Rafael Espindola d00c2765aa Collect the Addend for external relocs.
This fixes 2013-04-04-RelocAddend.ll. We don't have a testcase for non external
relocs with an Addend. I will try to write one.

llvm-svn: 180767
2013-04-30 01:29:57 +00:00
Rafael Espindola f1f1c626e7 Propagate relocation info to resolveRelocation.
This gets most of the MCJITs tests passing with MachO.

llvm-svn: 180716
2013-04-29 17:24:34 +00:00
Ulrich Weigand 78e9765b19 Respect Addend when processing MCJIT relocations to local/global symbols.
When the RuntimeDyldELF::processRelocationRef routine finds the target
symbol of a relocation in the local or global symbol table, it performs
a section-relative relocation:

    Value.SectionID = lsi->second.first;
    Value.Addend = lsi->second.second;

At this point, however, any Addend that might have been specified in
the original relocation record is lost.  This is somewhat difficult to
trigger for relocations within the code section since they usually
do not contain non-zero Addends (when built with the default JIT code
model, in any case).  However, the problem can be reliably triggered
by a relocation within the data section caused by code like:

 int test[2] = { -1, 0 };
 int *p = &test[1];

The initializer of "p" will need a relocation to "test + 4".  On
platforms using RelA relocations this means an Addend of 4 is required.
Current code ignores this addend when processing the relocation,
resulting in incorrect execution.

Fixed by taking the Addend into account when processing relocations
to symbols found in the local or global symbol table.

Tested on x86_64-linux and powerpc64-linux.

llvm-svn: 178869
2013-04-05 13:29:04 +00:00