Open llvmbot opened 15 years ago
Nate, have you seen this sort of problem?
The attached code sets up the problem situation - with a function in a module that's then removed, then does a reverse lookup of the address of the former function which I think should fail but succeeds returning the defunct function, then tries the forward lookup which fails as I would expect.
Extended Description
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.