[LLVMbugs] [Bug 5003] New: JITResolver:: getGlobalValueIndirectSym may return incorrect value

bugzilla-daemon at cs.uiuc.edu bugzilla-daemon at cs.uiuc.edu
Thu Sep 17 15:21:49 PDT 2009


http://llvm.org/bugs/show_bug.cgi?id=5003

           Summary: JITResolver::getGlobalValueIndirectSym may return
                    incorrect value
           Product: libraries
           Version: trunk
          Platform: PC
        OS/Version: MacOS X
            Status: NEW
          Severity: normal
          Priority: P2
         Component: Target-Independent JIT
        AssignedTo: unassignedbugs at nondot.org
        ReportedBy: pgurd at rapidmind.com
                CC: llvmbugs at cs.uiuc.edu


Created an attachment (id=3527)
 --> (http://llvm.org/bugs/attachment.cgi?id=3527)
Patch to clear the Global Value Indirect Symbol map at the end of
finishFunctiion

In lib/ExecutionEngine/JIT/JIREmitter.cpp:

The JITResolverState class has a GlobalToIndirectSymMap, which maps a
GlobalValue pointer to its corresponding indirect symbol location.

The GlobalToIndirectSymMap persistently records maps of GlobalValues to
indirect symbol locations for all functions seen. That is. it seems that it is
never cleared.

The function JITResolver::getGlobalIndirectSym looks up its argument
GlobalValue* in this map.

If a GlobalValue* in a function was allocated with new() and later released
when processing of that function is complete, then it is possible that the
space so made available could be re-used later for a completely different
GlobalValue* in a different function.

When that happens (as it did for us!), the line of code

void *&IndirectSym = state.getGlobalToIndirectSymMap(locked)[GV];

in getGlobalIndirectSym will find and return the long gone first use of that
pointer value, rather than creating a new entry in the map and returning it,
resulting in incorrect JIT code.

This was noticed in x86_64 Mac OS X code, which needs to use the indirect
symbol map to load addresses, persumably because there is no 64 bit immediate
load instruction.

We worked around this issue by adding code at the end of the finishFunction
function to clear the map. I am guessing that this may not be the optimal way
to fix this. In any case, I have attached the patch, in case it might be of any
help.


-- 
Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.



More information about the llvm-bugs mailing list