[llvm] r188022 - [Object] Split the ELF interface into 3 parts.

[Renato Golin]

On 12 August 2013 15:11, Renato Golin <renato.golin at linaro.org> wrote:

> Looks like an error on the way it's resolving the ARM relocations on MCJIT
> for the global constructors:
>

Michael,

So, below is the debug trace with some info. I don't understand much what's
going on, so I'll just walk through the debug result. I can give you access
to my Chromebook and work with you to solve this problem, let me know if
you need anything.

If you feel we'll need more investigation, maybe we should revert the patch
temporarily to keep the bots green, and re-commit when this problem is
fixed.


No, on to the problem...

The simple ctor/dtor module gets loaded and need to resolve the relocations:

llvm::RuntimeDyldImpl::resolveRelocationList()

  For each loaded section (Address != 0), call: resolveRelocation(RE,
Value);
  Our section is:

(gdb) p Section
$9 = (const llvm::SectionEntry &) @0xdb9d48: {Name = {static npos =
4294967295, Data = 0xdb5b1d ".init_array", Length = 11},
  Address = 0x76fdf004 "", Size = 4, LoadAddress = 1996353540, StubOffset =
4, ObjAddress = 0}

Note that the address is not null, but the ObjAddress is.

Down there, on llvm::RuntimeDyldELF::resolveARMRelocation():

404  // Write a 32bit value to relocation address, taking into account the
405  // implicit addend encoded in the target.
406  case ELF::R_ARM_TARGET1:
407  case ELF::R_ARM_ABS32:
408    *TargetPtr = *Placeholder + Value;
409    break;

Where:

  uint32_t *Placeholder = reinterpret_cast<uint32_t*>(Section.ObjAddress +
                                                      Offset);

Since the ObjAddress is 0, *Placeholder segfaults.

cheers,
--renato
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20130812/8c4220ab/attachment.html>