[LLVMbugs] [Bug 3165] New: removing ModuleProvider from ExecutionEngine doesn' t remove reverse global mappings

bugzilla-daemon at cs.uiuc.edu bugzilla-daemon at cs.uiuc.edu
Thu Dec 4 19:13:20 PST 2008


           Summary: removing ModuleProvider from ExecutionEngine doesn't
                    remove reverse global mappings
           Product: new-bugs
           Version: unspecified
          Platform: PC
        OS/Version: Linux
            Status: NEW
          Severity: normal
          Priority: P2
         Component: new bugs
        AssignedTo: unassignedbugs at nondot.org
        ReportedBy: flld0 at greynode.net
                CC: llvmbugs at cs.uiuc.edu

Created an attachment (id=2266)
 --> (http://llvm.org/bugs/attachment.cgi?id=2266)
Code to demonstrate the problem

When a module provider is removed from the ExecutionEngine, forward mappings
from the module's GlobalValues are removed, but the reverse mappings remain.

The problem seems to me to be in
ExecutionEngine::clearGlobalMappingsFromModule. It loops over the module's
global mappings, calling std::map<...>::erase(...) on both the forward and
reverse maps. However, the variant of erase being called is the erase-by-key
variant, and the GlobalValue * is passed to both calls. It's the key in the
first map, but the value in the second.

The obvious fix would be to look up the GlobalValue * in the first map to get
the void * address, then erase the address from the reverse map and the
GlobalValue * from the forward map.

But: I've had one LLVM developer (Nickolas Lewycky) suggest to me, as a
workaround for another problem, mapping multiple GlobalValue *'s to the same
address. I'm not too worried about my particular workaround case, but if there
are other more significant cases where multiple GlobalValue *'s map to the same
address, then the whole notion of storing the reverse mapping in a
single-valued map doesn't work.

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