[llvm-bugs] [Bug 26116] New: RuntimeDyldCOFFI386 error on IMAGE_REL_I386_REL32 for global function address mapping

[via llvm-bugs]

https://llvm.org/bugs/show_bug.cgi?id=26116

            Bug ID: 26116
           Summary: RuntimeDyldCOFFI386 error on IMAGE_REL_I386_REL32 for
                    global function address mapping
           Product: libraries
           Version: trunk
          Hardware: PC
                OS: All
            Status: NEW
          Severity: release blocker
          Priority: P
         Component: Generic Execution Engine Support
          Assignee: unassignedbugs at nondot.org
          Reporter: vivien.millet at gmail.com
                CC: llvm-bugs at lists.llvm.org
    Classification: Unclassified

In RuntimeDyldCOFFI386.h
After Line: 151
We have : 
uint64_t Result = Sections[RE.Sections.SectionA].getLoadAddress() -
              Section.getLoadAddress() + RE.Addend - 4 - RE.Offset;

BUT
In case of global native C++ function mapping
(ExecutionEngine::addGlobalMapping(...)), RE.Sections.SectionA equals -1
(0xffffffff) which triggers a bad index assertion. 

Analysing and comparing to the In RuntimeDyldCOFFX86_64, we should treat a
special case when SectionA == -1 

I propose that code which works fine for me and retrieves on code generation
the good global address (i put the whole switch case)

 case COFF::IMAGE_REL_I386_REL32: {
      // 32-bit relative displacement to the target.
      uint64_t Result;
      if(RE.Sections.SectionA == static_cast<uint32_t>(-1))
      {
          uint64_t FinalAddress = Section.getLoadAddressWithOffset(RE.Offset);
          Value -= FinalAddress + 4;
          Result = Value + RE.Addend;
      }
      else
      {
          Result = Sections[RE.Sections.SectionA].getLoadAddress() -
              Section.getLoadAddress() + RE.Addend - 4 - RE.Offset;
      }
      assert(static_cast<int32_t>(Result) <= INT32_MAX &&
             "relocation overflow");
      assert(static_cast<int32_t>(Result) >= INT32_MIN &&
             "relocation underflow");
      DEBUG(dbgs() << "\t\tOffset: " << RE.Offset
                   << " RelType: IMAGE_REL_I386_REL32"
                   << " TargetSection: " << RE.Sections.SectionA
                   << " Value: " << format("0x%08" PRIx32, Result) << '\n');
      writeBytesUnaligned(Result, Target, 4);
      break;

-- 
You are receiving this mail because:
You are on the CC list for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-bugs/attachments/20160111/723f0023/attachment.html>