Deal with error handling better.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@34887 91177308-0d34-0410-b5e6-96231b3b80d8
This commit is contained in:
Reid Spencer
2007-03-03 18:19:18 +00:00
parent c923435a59
commit d4c0e62413
5 changed files with 31 additions and 14 deletions
@@ -18,6 +18,7 @@
#include "llvm/DerivedTypes.h"
#include "llvm/Module.h"
#include "llvm/ModuleProvider.h"
#include <iostream>
using namespace llvm;
static struct RegisterInterp {
@@ -31,13 +32,20 @@ namespace llvm {
/// create - Create a new interpreter object. This can never fail.
///
ExecutionEngine *Interpreter::create(ModuleProvider *MP) {
Module *M;
try {
M = MP->materializeModule();
} catch (...) {
return 0; // error materializing the module.
}
ExecutionEngine *Interpreter::create(ModuleProvider *MP, std::string* ErrStr) {
// Tell this ModuleProvide to materialize and release the module
Module *M = MP->releaseModule(ErrStr);
if (!M)
// We got an error, just return 0
return 0;
// This is a bit nasty, but the ExecutionEngine won't be able to delete the
// module due to use/def issues if we don't delete this MP here. Below we
// construct a new Interpreter with the Module we just got. This creates a
// new ExistingModuleProvider in the EE instance. Consequently, MP is left
// dangling and it contains references into the module which cause problems
// when the module is deleted via the ExistingModuleProvide via EE.
delete MP;
// FIXME: This should probably compute the entire data layout
std::string DataLayout;