<div dir="ltr">On 12 August 2013 15:11, Renato Golin <span dir="ltr"><<a href="mailto:renato.golin@linaro.org" target="_blank">renato.golin@linaro.org</a>></span> wrote:<br><div class="gmail_extra"><div class="gmail_quote">
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div dir="ltr"><div class="im"><span style="color:rgb(34,34,34)">Looks like an error on the way it's resolving the ARM relocations on MCJIT for the global constructors:</span></div>
</div></blockquote><div></div></div><br></div><div class="gmail_extra">Michael,</div><div class="gmail_extra"><br></div><div class="gmail_extra">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.</div>
<div class="gmail_extra"><br></div><div class="gmail_extra">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.</div>
<div class="gmail_extra"><br></div><div class="gmail_extra"><br></div><div class="gmail_extra">No, on to the problem...</div><div class="gmail_extra"><br></div><div class="gmail_extra">The simple ctor/dtor module gets loaded and need to resolve the relocations:</div>
<div class="gmail_extra"><br></div><div class="gmail_extra">llvm::RuntimeDyldImpl::resolveRelocationList()<br></div><div class="gmail_extra"><br></div><div class="gmail_extra">  For each loaded section (Address != 0), call: resolveRelocation(RE, Value);</div>
<div class="gmail_extra">  Our section is:</div><div class="gmail_extra"><br></div><div class="gmail_extra"><div class="gmail_extra">(gdb) p Section</div><div class="gmail_extra">$9 = (const llvm::SectionEntry &) @0xdb9d48: {Name = {static npos = 4294967295, Data = 0xdb5b1d ".init_array", Length = 11}, </div>
<div class="gmail_extra">  Address = 0x76fdf004 "", Size = 4, LoadAddress = 1996353540, StubOffset = 4, ObjAddress = 0}</div><div><br></div><div>Note that the address is not null, but the ObjAddress is.</div><div>
<br></div><div>Down there, on llvm::RuntimeDyldELF::resolveARMRelocation():</div><div><br></div><div><div>404<span class="" style="white-space:pre">    </span>  // Write a 32bit value to relocation address, taking into account the</div>
<div>405<span class="" style="white-space:pre"> </span>  // implicit addend encoded in the target.</div><div>406<span class="" style="white-space:pre">     </span>  case ELF::R_ARM_TARGET1:</div><div>407<span class="" style="white-space:pre">      </span>  case ELF::R_ARM_ABS32:</div>
<div>408<span class="" style="white-space:pre"> </span>    *TargetPtr = *Placeholder + Value;</div><div>409<span class="" style="white-space:pre">  </span>    break;</div></div><div><br></div><div>Where:</div><div><br></div>
<div><div>  uint32_t *Placeholder = reinterpret_cast<uint32_t*>(Section.ObjAddress +</div><div>                                                      Offset);</div></div><div><br></div><div>Since the ObjAddress is 0, *Placeholder segfaults.</div>
<div><br></div><div>cheers,</div><div>--renato</div></div></div>