llvm-project/lldb/source/Expression/ClangExpressionParser.cpp

599 lines
22 KiB
C++
Raw Normal View History

This is a major refactoring of the expression parser. The goal is to separate the parser's data from the data belonging to the parser's clients. This allows clients to use the parser to obtain (for example) a JIT compiled function or some DWARF code, and then discard the parser state. Previously, parser state was held in ClangExpression and used liberally by ClangFunction, which inherited from ClangExpression. The main effects of this refactoring are: - reducing ClangExpression to an abstract class that declares methods that any client must expose to the expression parser, - moving the code specific to implementing the "expr" command from ClangExpression and CommandObjectExpression into ClangUserExpression, a new class, - moving the common parser interaction code from ClangExpression into ClangExpressionParser, a new class, and - making ClangFunction rely only on ClangExpressionParser and not depend on the internal implementation of ClangExpression. Side effects include: - the compiler interaction code has been factored out of ClangFunction and is now in an AST pass (ASTStructExtractor), - the header file for ClangFunction is now fully documented, - several bugs that only popped up when Clang was deallocated (which never happened, since the lifetime of the compiler was essentially infinite) are now fixed, and - the developer-only "call" command has been disabled. I have tested the expr command and the Objective-C step-into code, which use ClangUserExpression and ClangFunction, respectively, and verified that they work. Please let me know if you encounter bugs or poor documentation. llvm-svn: 112249
2010-08-27 09:01:44 +08:00
//===-- ClangExpressionParser.cpp -------------------------------*- C++ -*-===//
//
// The LLVM Compiler Infrastructure
//
// This file is distributed under the University of Illinois Open Source
// License. See LICENSE.TXT for details.
//
//===----------------------------------------------------------------------===//
#include "lldb/lldb-python.h"
This is a major refactoring of the expression parser. The goal is to separate the parser's data from the data belonging to the parser's clients. This allows clients to use the parser to obtain (for example) a JIT compiled function or some DWARF code, and then discard the parser state. Previously, parser state was held in ClangExpression and used liberally by ClangFunction, which inherited from ClangExpression. The main effects of this refactoring are: - reducing ClangExpression to an abstract class that declares methods that any client must expose to the expression parser, - moving the code specific to implementing the "expr" command from ClangExpression and CommandObjectExpression into ClangUserExpression, a new class, - moving the common parser interaction code from ClangExpression into ClangExpressionParser, a new class, and - making ClangFunction rely only on ClangExpressionParser and not depend on the internal implementation of ClangExpression. Side effects include: - the compiler interaction code has been factored out of ClangFunction and is now in an AST pass (ASTStructExtractor), - the header file for ClangFunction is now fully documented, - several bugs that only popped up when Clang was deallocated (which never happened, since the lifetime of the compiler was essentially infinite) are now fixed, and - the developer-only "call" command has been disabled. I have tested the expr command and the Objective-C step-into code, which use ClangUserExpression and ClangFunction, respectively, and verified that they work. Please let me know if you encounter bugs or poor documentation. llvm-svn: 112249
2010-08-27 09:01:44 +08:00
#include "lldb/Expression/ClangExpressionParser.h"
#include "lldb/Core/ArchSpec.h"
#include "lldb/Core/DataBufferHeap.h"
#include "lldb/Core/Debugger.h"
This is a major refactoring of the expression parser. The goal is to separate the parser's data from the data belonging to the parser's clients. This allows clients to use the parser to obtain (for example) a JIT compiled function or some DWARF code, and then discard the parser state. Previously, parser state was held in ClangExpression and used liberally by ClangFunction, which inherited from ClangExpression. The main effects of this refactoring are: - reducing ClangExpression to an abstract class that declares methods that any client must expose to the expression parser, - moving the code specific to implementing the "expr" command from ClangExpression and CommandObjectExpression into ClangUserExpression, a new class, - moving the common parser interaction code from ClangExpression into ClangExpressionParser, a new class, and - making ClangFunction rely only on ClangExpressionParser and not depend on the internal implementation of ClangExpression. Side effects include: - the compiler interaction code has been factored out of ClangFunction and is now in an AST pass (ASTStructExtractor), - the header file for ClangFunction is now fully documented, - several bugs that only popped up when Clang was deallocated (which never happened, since the lifetime of the compiler was essentially infinite) are now fixed, and - the developer-only "call" command has been disabled. I have tested the expr command and the Objective-C step-into code, which use ClangUserExpression and ClangFunction, respectively, and verified that they work. Please let me know if you encounter bugs or poor documentation. llvm-svn: 112249
2010-08-27 09:01:44 +08:00
#include "lldb/Core/Disassembler.h"
#include "lldb/Core/Stream.h"
#include "lldb/Core/StreamString.h"
This is a major refactoring of the expression parser. The goal is to separate the parser's data from the data belonging to the parser's clients. This allows clients to use the parser to obtain (for example) a JIT compiled function or some DWARF code, and then discard the parser state. Previously, parser state was held in ClangExpression and used liberally by ClangFunction, which inherited from ClangExpression. The main effects of this refactoring are: - reducing ClangExpression to an abstract class that declares methods that any client must expose to the expression parser, - moving the code specific to implementing the "expr" command from ClangExpression and CommandObjectExpression into ClangUserExpression, a new class, - moving the common parser interaction code from ClangExpression into ClangExpressionParser, a new class, and - making ClangFunction rely only on ClangExpressionParser and not depend on the internal implementation of ClangExpression. Side effects include: - the compiler interaction code has been factored out of ClangFunction and is now in an AST pass (ASTStructExtractor), - the header file for ClangFunction is now fully documented, - several bugs that only popped up when Clang was deallocated (which never happened, since the lifetime of the compiler was essentially infinite) are now fixed, and - the developer-only "call" command has been disabled. I have tested the expr command and the Objective-C step-into code, which use ClangUserExpression and ClangFunction, respectively, and verified that they work. Please let me know if you encounter bugs or poor documentation. llvm-svn: 112249
2010-08-27 09:01:44 +08:00
#include "lldb/Expression/ClangASTSource.h"
#include "lldb/Expression/ClangExpression.h"
#include "lldb/Expression/ClangExpressionDeclMap.h"
#include "lldb/Expression/IRExecutionUnit.h"
#include "lldb/Expression/IRDynamicChecks.h"
This commit changes the way LLDB executes user expressions. Previously, ClangUserExpression assumed that if there was a constant result for an expression then it could be determined during parsing. In particular, the IRInterpreter ran while parser state (in particular, ClangExpressionDeclMap) was present. This approach is flawed, because the IRInterpreter actually is capable of using external variables, and hence the result might be different each run. Until now, we papered over this flaw by re-parsing the expression each time we ran it. I have rewritten the IRInterpreter to be completely independent of the ClangExpressionDeclMap. Instead of special-casing external variable lookup, which ties the IRInterpreter closely to LLDB, we now interpret the exact same IR that the JIT would see. This IR assumes that materialization has occurred; hence the recent implementation of the Materializer, which does not require parser state (in the form of ClangExpressionDeclMap) to be present. Materialization, interpretation, and dematerialization are now all independent of parsing. This means that in theory we can parse expressions once and run them many times. I have three outstanding tasks before shutting this down: - First, I will ensure that all of this works with core files. Core files have a Process but do not allow allocating memory, which currently confuses materialization. - Second, I will make expression breakpoint conditions remember their ClangUserExpression and re-use it. - Third, I will tear out all the redundant code (for example, materialization logic in ClangExpressionDeclMap) that is no longer used. While implementing this fix, I also found a bug in IRForTarget's handling of floating-point constants. This should be fixed. llvm-svn: 179801
2013-04-19 06:06:33 +08:00
#include "lldb/Expression/IRInterpreter.h"
This is a major refactoring of the expression parser. The goal is to separate the parser's data from the data belonging to the parser's clients. This allows clients to use the parser to obtain (for example) a JIT compiled function or some DWARF code, and then discard the parser state. Previously, parser state was held in ClangExpression and used liberally by ClangFunction, which inherited from ClangExpression. The main effects of this refactoring are: - reducing ClangExpression to an abstract class that declares methods that any client must expose to the expression parser, - moving the code specific to implementing the "expr" command from ClangExpression and CommandObjectExpression into ClangUserExpression, a new class, - moving the common parser interaction code from ClangExpression into ClangExpressionParser, a new class, and - making ClangFunction rely only on ClangExpressionParser and not depend on the internal implementation of ClangExpression. Side effects include: - the compiler interaction code has been factored out of ClangFunction and is now in an AST pass (ASTStructExtractor), - the header file for ClangFunction is now fully documented, - several bugs that only popped up when Clang was deallocated (which never happened, since the lifetime of the compiler was essentially infinite) are now fixed, and - the developer-only "call" command has been disabled. I have tested the expr command and the Objective-C step-into code, which use ClangUserExpression and ClangFunction, respectively, and verified that they work. Please let me know if you encounter bugs or poor documentation. llvm-svn: 112249
2010-08-27 09:01:44 +08:00
#include "lldb/Target/ExecutionContext.h"
#include "lldb/Target/ObjCLanguageRuntime.h"
This is a major refactoring of the expression parser. The goal is to separate the parser's data from the data belonging to the parser's clients. This allows clients to use the parser to obtain (for example) a JIT compiled function or some DWARF code, and then discard the parser state. Previously, parser state was held in ClangExpression and used liberally by ClangFunction, which inherited from ClangExpression. The main effects of this refactoring are: - reducing ClangExpression to an abstract class that declares methods that any client must expose to the expression parser, - moving the code specific to implementing the "expr" command from ClangExpression and CommandObjectExpression into ClangUserExpression, a new class, - moving the common parser interaction code from ClangExpression into ClangExpressionParser, a new class, and - making ClangFunction rely only on ClangExpressionParser and not depend on the internal implementation of ClangExpression. Side effects include: - the compiler interaction code has been factored out of ClangFunction and is now in an AST pass (ASTStructExtractor), - the header file for ClangFunction is now fully documented, - several bugs that only popped up when Clang was deallocated (which never happened, since the lifetime of the compiler was essentially infinite) are now fixed, and - the developer-only "call" command has been disabled. I have tested the expr command and the Objective-C step-into code, which use ClangUserExpression and ClangFunction, respectively, and verified that they work. Please let me know if you encounter bugs or poor documentation. llvm-svn: 112249
2010-08-27 09:01:44 +08:00
#include "lldb/Target/Process.h"
#include "lldb/Target/Target.h"
#include "clang/AST/ASTContext.h"
#include "clang/AST/ExternalASTSource.h"
#include "clang/Basic/FileManager.h"
#include "clang/Basic/TargetInfo.h"
#include "clang/Basic/Version.h"
#include "clang/CodeGen/CodeGenAction.h"
#include "clang/CodeGen/ModuleBuilder.h"
#include "clang/Driver/CC1Options.h"
#include "clang/Driver/OptTable.h"
#include "clang/Frontend/CompilerInstance.h"
#include "clang/Frontend/CompilerInvocation.h"
#include "clang/Frontend/FrontendActions.h"
#include "clang/Frontend/FrontendDiagnostic.h"
#include "clang/Frontend/FrontendPluginRegistry.h"
#include "clang/Frontend/TextDiagnosticBuffer.h"
#include "clang/Frontend/TextDiagnosticPrinter.h"
#include "clang/Lex/Preprocessor.h"
#include "clang/Parse/ParseAST.h"
#include "clang/Rewrite/Frontend/FrontendActions.h"
This is a major refactoring of the expression parser. The goal is to separate the parser's data from the data belonging to the parser's clients. This allows clients to use the parser to obtain (for example) a JIT compiled function or some DWARF code, and then discard the parser state. Previously, parser state was held in ClangExpression and used liberally by ClangFunction, which inherited from ClangExpression. The main effects of this refactoring are: - reducing ClangExpression to an abstract class that declares methods that any client must expose to the expression parser, - moving the code specific to implementing the "expr" command from ClangExpression and CommandObjectExpression into ClangUserExpression, a new class, - moving the common parser interaction code from ClangExpression into ClangExpressionParser, a new class, and - making ClangFunction rely only on ClangExpressionParser and not depend on the internal implementation of ClangExpression. Side effects include: - the compiler interaction code has been factored out of ClangFunction and is now in an AST pass (ASTStructExtractor), - the header file for ClangFunction is now fully documented, - several bugs that only popped up when Clang was deallocated (which never happened, since the lifetime of the compiler was essentially infinite) are now fixed, and - the developer-only "call" command has been disabled. I have tested the expr command and the Objective-C step-into code, which use ClangUserExpression and ClangFunction, respectively, and verified that they work. Please let me know if you encounter bugs or poor documentation. llvm-svn: 112249
2010-08-27 09:01:44 +08:00
#include "clang/Sema/SemaConsumer.h"
#include "clang/StaticAnalyzer/Frontend/FrontendActions.h"
This is a major refactoring of the expression parser. The goal is to separate the parser's data from the data belonging to the parser's clients. This allows clients to use the parser to obtain (for example) a JIT compiled function or some DWARF code, and then discard the parser state. Previously, parser state was held in ClangExpression and used liberally by ClangFunction, which inherited from ClangExpression. The main effects of this refactoring are: - reducing ClangExpression to an abstract class that declares methods that any client must expose to the expression parser, - moving the code specific to implementing the "expr" command from ClangExpression and CommandObjectExpression into ClangUserExpression, a new class, - moving the common parser interaction code from ClangExpression into ClangExpressionParser, a new class, and - making ClangFunction rely only on ClangExpressionParser and not depend on the internal implementation of ClangExpression. Side effects include: - the compiler interaction code has been factored out of ClangFunction and is now in an AST pass (ASTStructExtractor), - the header file for ClangFunction is now fully documented, - several bugs that only popped up when Clang was deallocated (which never happened, since the lifetime of the compiler was essentially infinite) are now fixed, and - the developer-only "call" command has been disabled. I have tested the expr command and the Objective-C step-into code, which use ClangUserExpression and ClangFunction, respectively, and verified that they work. Please let me know if you encounter bugs or poor documentation. llvm-svn: 112249
2010-08-27 09:01:44 +08:00
#include "llvm/ADT/StringRef.h"
#include "llvm/ExecutionEngine/ExecutionEngine.h"
#include "llvm/Support/Debug.h"
#include "llvm/Support/TargetSelect.h"
Added the ability to get the return value from a ThreadPlanCallFunction thread plan. In order to get the return value, you can call: void ThreadPlanCallFunction::RequestReturnValue (lldb::ValueSP &return_value_sp); This registers a shared pointer to a return value that will get filled in if everything goes well. After the thread plan is run the return value will be extracted for you. Added an ifdef to be able to switch between the LLVM MCJIT and the standand JIT. We currently have the standard JIT selected because we have some work to do to get the MCJIT fuctioning properly. Added the ability to call functions with 6 argument in the x86_64 ABI. Added the ability for GDBRemoteCommunicationClient to detect if the allocate and deallocate memory packets are supported and to not call allocate memory ("_M") or deallocate ("_m") if we find they aren't supported. Modified the ProcessGDBRemote::DoAllocateMemory(...) and ProcessGDBRemote::DoDeallocateMemory(...) to be able to deal with the allocate and deallocate memory packets not being supported. If they are not supported, ProcessGDBRemote will switch to calling "mmap" and "munmap" to allocate and deallocate memory instead using our trivial function call support. Modified the "void ProcessGDBRemote::DidLaunchOrAttach()" to correctly ignore the qHostInfo triple information if any was specified in the target. Currently if the target only specifies an architecture when creating the target: (lldb) target create --arch i386 a.out Then the vendor, os and environemnt will be adopted by the target. If the target was created with any triple that specifies more than the arch: (lldb) target create --arch i386-unknown-unknown a.out Then the target will maintain its triple and not adopt any new values. This can be used to help force bare board debugging where the dynamic loader for static files will get used and users can then use "target modules load ..." to set addressses for any files that are desired. Added back some convenience functions to the lldb_private::RegisterContext class for writing registers with unsigned values. Also made all RegisterContext constructors explicit to make sure we know when an integer is being converted to a RegisterValue. llvm-svn: 131370
2011-05-15 09:25:55 +08:00
#if defined(__FreeBSD__)
#define USE_STANDARD_JIT
#endif
Added the ability to get the return value from a ThreadPlanCallFunction thread plan. In order to get the return value, you can call: void ThreadPlanCallFunction::RequestReturnValue (lldb::ValueSP &return_value_sp); This registers a shared pointer to a return value that will get filled in if everything goes well. After the thread plan is run the return value will be extracted for you. Added an ifdef to be able to switch between the LLVM MCJIT and the standand JIT. We currently have the standard JIT selected because we have some work to do to get the MCJIT fuctioning properly. Added the ability to call functions with 6 argument in the x86_64 ABI. Added the ability for GDBRemoteCommunicationClient to detect if the allocate and deallocate memory packets are supported and to not call allocate memory ("_M") or deallocate ("_m") if we find they aren't supported. Modified the ProcessGDBRemote::DoAllocateMemory(...) and ProcessGDBRemote::DoDeallocateMemory(...) to be able to deal with the allocate and deallocate memory packets not being supported. If they are not supported, ProcessGDBRemote will switch to calling "mmap" and "munmap" to allocate and deallocate memory instead using our trivial function call support. Modified the "void ProcessGDBRemote::DidLaunchOrAttach()" to correctly ignore the qHostInfo triple information if any was specified in the target. Currently if the target only specifies an architecture when creating the target: (lldb) target create --arch i386 a.out Then the vendor, os and environemnt will be adopted by the target. If the target was created with any triple that specifies more than the arch: (lldb) target create --arch i386-unknown-unknown a.out Then the target will maintain its triple and not adopt any new values. This can be used to help force bare board debugging where the dynamic loader for static files will get used and users can then use "target modules load ..." to set addressses for any files that are desired. Added back some convenience functions to the lldb_private::RegisterContext class for writing registers with unsigned values. Also made all RegisterContext constructors explicit to make sure we know when an integer is being converted to a RegisterValue. llvm-svn: 131370
2011-05-15 09:25:55 +08:00
#if defined (USE_STANDARD_JIT)
This is a major refactoring of the expression parser. The goal is to separate the parser's data from the data belonging to the parser's clients. This allows clients to use the parser to obtain (for example) a JIT compiled function or some DWARF code, and then discard the parser state. Previously, parser state was held in ClangExpression and used liberally by ClangFunction, which inherited from ClangExpression. The main effects of this refactoring are: - reducing ClangExpression to an abstract class that declares methods that any client must expose to the expression parser, - moving the code specific to implementing the "expr" command from ClangExpression and CommandObjectExpression into ClangUserExpression, a new class, - moving the common parser interaction code from ClangExpression into ClangExpressionParser, a new class, and - making ClangFunction rely only on ClangExpressionParser and not depend on the internal implementation of ClangExpression. Side effects include: - the compiler interaction code has been factored out of ClangFunction and is now in an AST pass (ASTStructExtractor), - the header file for ClangFunction is now fully documented, - several bugs that only popped up when Clang was deallocated (which never happened, since the lifetime of the compiler was essentially infinite) are now fixed, and - the developer-only "call" command has been disabled. I have tested the expr command and the Objective-C step-into code, which use ClangUserExpression and ClangFunction, respectively, and verified that they work. Please let me know if you encounter bugs or poor documentation. llvm-svn: 112249
2010-08-27 09:01:44 +08:00
#include "llvm/ExecutionEngine/JIT.h"
Added the ability to get the return value from a ThreadPlanCallFunction thread plan. In order to get the return value, you can call: void ThreadPlanCallFunction::RequestReturnValue (lldb::ValueSP &return_value_sp); This registers a shared pointer to a return value that will get filled in if everything goes well. After the thread plan is run the return value will be extracted for you. Added an ifdef to be able to switch between the LLVM MCJIT and the standand JIT. We currently have the standard JIT selected because we have some work to do to get the MCJIT fuctioning properly. Added the ability to call functions with 6 argument in the x86_64 ABI. Added the ability for GDBRemoteCommunicationClient to detect if the allocate and deallocate memory packets are supported and to not call allocate memory ("_M") or deallocate ("_m") if we find they aren't supported. Modified the ProcessGDBRemote::DoAllocateMemory(...) and ProcessGDBRemote::DoDeallocateMemory(...) to be able to deal with the allocate and deallocate memory packets not being supported. If they are not supported, ProcessGDBRemote will switch to calling "mmap" and "munmap" to allocate and deallocate memory instead using our trivial function call support. Modified the "void ProcessGDBRemote::DidLaunchOrAttach()" to correctly ignore the qHostInfo triple information if any was specified in the target. Currently if the target only specifies an architecture when creating the target: (lldb) target create --arch i386 a.out Then the vendor, os and environemnt will be adopted by the target. If the target was created with any triple that specifies more than the arch: (lldb) target create --arch i386-unknown-unknown a.out Then the target will maintain its triple and not adopt any new values. This can be used to help force bare board debugging where the dynamic loader for static files will get used and users can then use "target modules load ..." to set addressses for any files that are desired. Added back some convenience functions to the lldb_private::RegisterContext class for writing registers with unsigned values. Also made all RegisterContext constructors explicit to make sure we know when an integer is being converted to a RegisterValue. llvm-svn: 131370
2011-05-15 09:25:55 +08:00
#else
#include "llvm/ExecutionEngine/MCJIT.h"
#endif
#include "llvm/IR/LLVMContext.h"
#include "llvm/IR/Module.h"
This is a major refactoring of the expression parser. The goal is to separate the parser's data from the data belonging to the parser's clients. This allows clients to use the parser to obtain (for example) a JIT compiled function or some DWARF code, and then discard the parser state. Previously, parser state was held in ClangExpression and used liberally by ClangFunction, which inherited from ClangExpression. The main effects of this refactoring are: - reducing ClangExpression to an abstract class that declares methods that any client must expose to the expression parser, - moving the code specific to implementing the "expr" command from ClangExpression and CommandObjectExpression into ClangUserExpression, a new class, - moving the common parser interaction code from ClangExpression into ClangExpressionParser, a new class, and - making ClangFunction rely only on ClangExpressionParser and not depend on the internal implementation of ClangExpression. Side effects include: - the compiler interaction code has been factored out of ClangFunction and is now in an AST pass (ASTStructExtractor), - the header file for ClangFunction is now fully documented, - several bugs that only popped up when Clang was deallocated (which never happened, since the lifetime of the compiler was essentially infinite) are now fixed, and - the developer-only "call" command has been disabled. I have tested the expr command and the Objective-C step-into code, which use ClangUserExpression and ClangFunction, respectively, and verified that they work. Please let me know if you encounter bugs or poor documentation. llvm-svn: 112249
2010-08-27 09:01:44 +08:00
#include "llvm/Support/ErrorHandling.h"
#include "llvm/Support/MemoryBuffer.h"
#include "llvm/Support/DynamicLibrary.h"
#include "llvm/Support/Host.h"
#include "llvm/Support/Signals.h"
This is a major refactoring of the expression parser. The goal is to separate the parser's data from the data belonging to the parser's clients. This allows clients to use the parser to obtain (for example) a JIT compiled function or some DWARF code, and then discard the parser state. Previously, parser state was held in ClangExpression and used liberally by ClangFunction, which inherited from ClangExpression. The main effects of this refactoring are: - reducing ClangExpression to an abstract class that declares methods that any client must expose to the expression parser, - moving the code specific to implementing the "expr" command from ClangExpression and CommandObjectExpression into ClangUserExpression, a new class, - moving the common parser interaction code from ClangExpression into ClangExpressionParser, a new class, and - making ClangFunction rely only on ClangExpressionParser and not depend on the internal implementation of ClangExpression. Side effects include: - the compiler interaction code has been factored out of ClangFunction and is now in an AST pass (ASTStructExtractor), - the header file for ClangFunction is now fully documented, - several bugs that only popped up when Clang was deallocated (which never happened, since the lifetime of the compiler was essentially infinite) are now fixed, and - the developer-only "call" command has been disabled. I have tested the expr command and the Objective-C step-into code, which use ClangUserExpression and ClangFunction, respectively, and verified that they work. Please let me know if you encounter bugs or poor documentation. llvm-svn: 112249
2010-08-27 09:01:44 +08:00
using namespace clang;
using namespace llvm;
using namespace lldb_private;
//===----------------------------------------------------------------------===//
// Utility Methods for Clang
//===----------------------------------------------------------------------===//
std::string GetBuiltinIncludePath(const char *Argv0) {
llvm::sys::Path P =
llvm::sys::Path::GetMainExecutable(Argv0,
(void*)(intptr_t) GetBuiltinIncludePath);
if (!P.isEmpty()) {
P.eraseComponent(); // Remove /clang from foo/bin/clang
P.eraseComponent(); // Remove /bin from foo/bin
// Get foo/lib/clang/<version>/include
P.appendComponent("lib");
P.appendComponent("clang");
P.appendComponent(CLANG_VERSION_STRING);
P.appendComponent("include");
}
return P.str();
}
//===----------------------------------------------------------------------===//
// Main driver for Clang
//===----------------------------------------------------------------------===//
static void LLVMErrorHandler(void *UserData, const std::string &Message) {
DiagnosticsEngine &Diags = *static_cast<DiagnosticsEngine*>(UserData);
This is a major refactoring of the expression parser. The goal is to separate the parser's data from the data belonging to the parser's clients. This allows clients to use the parser to obtain (for example) a JIT compiled function or some DWARF code, and then discard the parser state. Previously, parser state was held in ClangExpression and used liberally by ClangFunction, which inherited from ClangExpression. The main effects of this refactoring are: - reducing ClangExpression to an abstract class that declares methods that any client must expose to the expression parser, - moving the code specific to implementing the "expr" command from ClangExpression and CommandObjectExpression into ClangUserExpression, a new class, - moving the common parser interaction code from ClangExpression into ClangExpressionParser, a new class, and - making ClangFunction rely only on ClangExpressionParser and not depend on the internal implementation of ClangExpression. Side effects include: - the compiler interaction code has been factored out of ClangFunction and is now in an AST pass (ASTStructExtractor), - the header file for ClangFunction is now fully documented, - several bugs that only popped up when Clang was deallocated (which never happened, since the lifetime of the compiler was essentially infinite) are now fixed, and - the developer-only "call" command has been disabled. I have tested the expr command and the Objective-C step-into code, which use ClangUserExpression and ClangFunction, respectively, and verified that they work. Please let me know if you encounter bugs or poor documentation. llvm-svn: 112249
2010-08-27 09:01:44 +08:00
Diags.Report(diag::err_fe_error_backend) << Message;
// We cannot recover from llvm errors.
assert(0);
This is a major refactoring of the expression parser. The goal is to separate the parser's data from the data belonging to the parser's clients. This allows clients to use the parser to obtain (for example) a JIT compiled function or some DWARF code, and then discard the parser state. Previously, parser state was held in ClangExpression and used liberally by ClangFunction, which inherited from ClangExpression. The main effects of this refactoring are: - reducing ClangExpression to an abstract class that declares methods that any client must expose to the expression parser, - moving the code specific to implementing the "expr" command from ClangExpression and CommandObjectExpression into ClangUserExpression, a new class, - moving the common parser interaction code from ClangExpression into ClangExpressionParser, a new class, and - making ClangFunction rely only on ClangExpressionParser and not depend on the internal implementation of ClangExpression. Side effects include: - the compiler interaction code has been factored out of ClangFunction and is now in an AST pass (ASTStructExtractor), - the header file for ClangFunction is now fully documented, - several bugs that only popped up when Clang was deallocated (which never happened, since the lifetime of the compiler was essentially infinite) are now fixed, and - the developer-only "call" command has been disabled. I have tested the expr command and the Objective-C step-into code, which use ClangUserExpression and ClangFunction, respectively, and verified that they work. Please let me know if you encounter bugs or poor documentation. llvm-svn: 112249
2010-08-27 09:01:44 +08:00
}
static FrontendAction *CreateFrontendBaseAction(CompilerInstance &CI) {
using namespace clang::frontend;
switch (CI.getFrontendOpts().ProgramAction) {
default:
llvm_unreachable("Invalid program action!");
case ASTDump: return new ASTDumpAction();
case ASTPrint: return new ASTPrintAction();
case ASTDumpXML: return new ASTDumpXMLAction();
This is a major refactoring of the expression parser. The goal is to separate the parser's data from the data belonging to the parser's clients. This allows clients to use the parser to obtain (for example) a JIT compiled function or some DWARF code, and then discard the parser state. Previously, parser state was held in ClangExpression and used liberally by ClangFunction, which inherited from ClangExpression. The main effects of this refactoring are: - reducing ClangExpression to an abstract class that declares methods that any client must expose to the expression parser, - moving the code specific to implementing the "expr" command from ClangExpression and CommandObjectExpression into ClangUserExpression, a new class, - moving the common parser interaction code from ClangExpression into ClangExpressionParser, a new class, and - making ClangFunction rely only on ClangExpressionParser and not depend on the internal implementation of ClangExpression. Side effects include: - the compiler interaction code has been factored out of ClangFunction and is now in an AST pass (ASTStructExtractor), - the header file for ClangFunction is now fully documented, - several bugs that only popped up when Clang was deallocated (which never happened, since the lifetime of the compiler was essentially infinite) are now fixed, and - the developer-only "call" command has been disabled. I have tested the expr command and the Objective-C step-into code, which use ClangUserExpression and ClangFunction, respectively, and verified that they work. Please let me know if you encounter bugs or poor documentation. llvm-svn: 112249
2010-08-27 09:01:44 +08:00
case ASTView: return new ASTViewAction();
case DumpRawTokens: return new DumpRawTokensAction();
case DumpTokens: return new DumpTokensAction();
case EmitAssembly: return new EmitAssemblyAction();
case EmitBC: return new EmitBCAction();
case EmitHTML: return new HTMLPrintAction();
case EmitLLVM: return new EmitLLVMAction();
case EmitLLVMOnly: return new EmitLLVMOnlyAction();
case EmitCodeGenOnly: return new EmitCodeGenOnlyAction();
case EmitObj: return new EmitObjAction();
case FixIt: return new FixItAction();
case GeneratePCH: return new GeneratePCHAction();
This is a major refactoring of the expression parser. The goal is to separate the parser's data from the data belonging to the parser's clients. This allows clients to use the parser to obtain (for example) a JIT compiled function or some DWARF code, and then discard the parser state. Previously, parser state was held in ClangExpression and used liberally by ClangFunction, which inherited from ClangExpression. The main effects of this refactoring are: - reducing ClangExpression to an abstract class that declares methods that any client must expose to the expression parser, - moving the code specific to implementing the "expr" command from ClangExpression and CommandObjectExpression into ClangUserExpression, a new class, - moving the common parser interaction code from ClangExpression into ClangExpressionParser, a new class, and - making ClangFunction rely only on ClangExpressionParser and not depend on the internal implementation of ClangExpression. Side effects include: - the compiler interaction code has been factored out of ClangFunction and is now in an AST pass (ASTStructExtractor), - the header file for ClangFunction is now fully documented, - several bugs that only popped up when Clang was deallocated (which never happened, since the lifetime of the compiler was essentially infinite) are now fixed, and - the developer-only "call" command has been disabled. I have tested the expr command and the Objective-C step-into code, which use ClangUserExpression and ClangFunction, respectively, and verified that they work. Please let me know if you encounter bugs or poor documentation. llvm-svn: 112249
2010-08-27 09:01:44 +08:00
case GeneratePTH: return new GeneratePTHAction();
case InitOnly: return new InitOnlyAction();
case ParseSyntaxOnly: return new SyntaxOnlyAction();
case PluginAction: {
for (FrontendPluginRegistry::iterator it =
FrontendPluginRegistry::begin(), ie = FrontendPluginRegistry::end();
it != ie; ++it) {
if (it->getName() == CI.getFrontendOpts().ActionName) {
llvm::OwningPtr<PluginASTAction> P(it->instantiate());
if (!P->ParseArgs(CI, CI.getFrontendOpts().PluginArgs))
return 0;
return P.take();
}
}
CI.getDiagnostics().Report(diag::err_fe_invalid_plugin_name)
<< CI.getFrontendOpts().ActionName;
return 0;
}
case PrintDeclContext: return new DeclContextPrintAction();
case PrintPreamble: return new PrintPreambleAction();
case PrintPreprocessedInput: return new PrintPreprocessedAction();
case RewriteMacros: return new RewriteMacrosAction();
case RewriteObjC: return new RewriteObjCAction();
case RewriteTest: return new RewriteTestAction();
//case RunAnalysis: return new AnalysisAction();
This is a major refactoring of the expression parser. The goal is to separate the parser's data from the data belonging to the parser's clients. This allows clients to use the parser to obtain (for example) a JIT compiled function or some DWARF code, and then discard the parser state. Previously, parser state was held in ClangExpression and used liberally by ClangFunction, which inherited from ClangExpression. The main effects of this refactoring are: - reducing ClangExpression to an abstract class that declares methods that any client must expose to the expression parser, - moving the code specific to implementing the "expr" command from ClangExpression and CommandObjectExpression into ClangUserExpression, a new class, - moving the common parser interaction code from ClangExpression into ClangExpressionParser, a new class, and - making ClangFunction rely only on ClangExpressionParser and not depend on the internal implementation of ClangExpression. Side effects include: - the compiler interaction code has been factored out of ClangFunction and is now in an AST pass (ASTStructExtractor), - the header file for ClangFunction is now fully documented, - several bugs that only popped up when Clang was deallocated (which never happened, since the lifetime of the compiler was essentially infinite) are now fixed, and - the developer-only "call" command has been disabled. I have tested the expr command and the Objective-C step-into code, which use ClangUserExpression and ClangFunction, respectively, and verified that they work. Please let me know if you encounter bugs or poor documentation. llvm-svn: 112249
2010-08-27 09:01:44 +08:00
case RunPreprocessorOnly: return new PreprocessOnlyAction();
}
}
static FrontendAction *CreateFrontendAction(CompilerInstance &CI) {
// Create the underlying action.
FrontendAction *Act = CreateFrontendBaseAction(CI);
if (!Act)
return 0;
// If there are any AST files to merge, create a frontend action
// adaptor to perform the merge.
if (!CI.getFrontendOpts().ASTMergeFiles.empty())
Act = new ASTMergeAction(Act, CI.getFrontendOpts().ASTMergeFiles);
This is a major refactoring of the expression parser. The goal is to separate the parser's data from the data belonging to the parser's clients. This allows clients to use the parser to obtain (for example) a JIT compiled function or some DWARF code, and then discard the parser state. Previously, parser state was held in ClangExpression and used liberally by ClangFunction, which inherited from ClangExpression. The main effects of this refactoring are: - reducing ClangExpression to an abstract class that declares methods that any client must expose to the expression parser, - moving the code specific to implementing the "expr" command from ClangExpression and CommandObjectExpression into ClangUserExpression, a new class, - moving the common parser interaction code from ClangExpression into ClangExpressionParser, a new class, and - making ClangFunction rely only on ClangExpressionParser and not depend on the internal implementation of ClangExpression. Side effects include: - the compiler interaction code has been factored out of ClangFunction and is now in an AST pass (ASTStructExtractor), - the header file for ClangFunction is now fully documented, - several bugs that only popped up when Clang was deallocated (which never happened, since the lifetime of the compiler was essentially infinite) are now fixed, and - the developer-only "call" command has been disabled. I have tested the expr command and the Objective-C step-into code, which use ClangUserExpression and ClangFunction, respectively, and verified that they work. Please let me know if you encounter bugs or poor documentation. llvm-svn: 112249
2010-08-27 09:01:44 +08:00
return Act;
}
//===----------------------------------------------------------------------===//
// Implementation of ClangExpressionParser
//===----------------------------------------------------------------------===//
ClangExpressionParser::ClangExpressionParser (ExecutionContextScope *exe_scope,
ClangExpression &expr) :
m_expr (expr),
This is a major refactoring of the expression parser. The goal is to separate the parser's data from the data belonging to the parser's clients. This allows clients to use the parser to obtain (for example) a JIT compiled function or some DWARF code, and then discard the parser state. Previously, parser state was held in ClangExpression and used liberally by ClangFunction, which inherited from ClangExpression. The main effects of this refactoring are: - reducing ClangExpression to an abstract class that declares methods that any client must expose to the expression parser, - moving the code specific to implementing the "expr" command from ClangExpression and CommandObjectExpression into ClangUserExpression, a new class, - moving the common parser interaction code from ClangExpression into ClangExpressionParser, a new class, and - making ClangFunction rely only on ClangExpressionParser and not depend on the internal implementation of ClangExpression. Side effects include: - the compiler interaction code has been factored out of ClangFunction and is now in an AST pass (ASTStructExtractor), - the header file for ClangFunction is now fully documented, - several bugs that only popped up when Clang was deallocated (which never happened, since the lifetime of the compiler was essentially infinite) are now fixed, and - the developer-only "call" command has been disabled. I have tested the expr command and the Objective-C step-into code, which use ClangUserExpression and ClangFunction, respectively, and verified that they work. Please let me know if you encounter bugs or poor documentation. llvm-svn: 112249
2010-08-27 09:01:44 +08:00
m_compiler (),
m_code_generator ()
This is a major refactoring of the expression parser. The goal is to separate the parser's data from the data belonging to the parser's clients. This allows clients to use the parser to obtain (for example) a JIT compiled function or some DWARF code, and then discard the parser state. Previously, parser state was held in ClangExpression and used liberally by ClangFunction, which inherited from ClangExpression. The main effects of this refactoring are: - reducing ClangExpression to an abstract class that declares methods that any client must expose to the expression parser, - moving the code specific to implementing the "expr" command from ClangExpression and CommandObjectExpression into ClangUserExpression, a new class, - moving the common parser interaction code from ClangExpression into ClangExpressionParser, a new class, and - making ClangFunction rely only on ClangExpressionParser and not depend on the internal implementation of ClangExpression. Side effects include: - the compiler interaction code has been factored out of ClangFunction and is now in an AST pass (ASTStructExtractor), - the header file for ClangFunction is now fully documented, - several bugs that only popped up when Clang was deallocated (which never happened, since the lifetime of the compiler was essentially infinite) are now fixed, and - the developer-only "call" command has been disabled. I have tested the expr command and the Objective-C step-into code, which use ClangUserExpression and ClangFunction, respectively, and verified that they work. Please let me know if you encounter bugs or poor documentation. llvm-svn: 112249
2010-08-27 09:01:44 +08:00
{
// Initialize targets first, so that --version shows registered targets.
static struct InitializeLLVM {
InitializeLLVM() {
llvm::InitializeAllTargets();
llvm::InitializeAllAsmPrinters();
llvm::InitializeAllTargetMCs();
llvm::InitializeAllDisassemblers();
llvm::DisablePrettyStackTrace = true;
This is a major refactoring of the expression parser. The goal is to separate the parser's data from the data belonging to the parser's clients. This allows clients to use the parser to obtain (for example) a JIT compiled function or some DWARF code, and then discard the parser state. Previously, parser state was held in ClangExpression and used liberally by ClangFunction, which inherited from ClangExpression. The main effects of this refactoring are: - reducing ClangExpression to an abstract class that declares methods that any client must expose to the expression parser, - moving the code specific to implementing the "expr" command from ClangExpression and CommandObjectExpression into ClangUserExpression, a new class, - moving the common parser interaction code from ClangExpression into ClangExpressionParser, a new class, and - making ClangFunction rely only on ClangExpressionParser and not depend on the internal implementation of ClangExpression. Side effects include: - the compiler interaction code has been factored out of ClangFunction and is now in an AST pass (ASTStructExtractor), - the header file for ClangFunction is now fully documented, - several bugs that only popped up when Clang was deallocated (which never happened, since the lifetime of the compiler was essentially infinite) are now fixed, and - the developer-only "call" command has been disabled. I have tested the expr command and the Objective-C step-into code, which use ClangUserExpression and ClangFunction, respectively, and verified that they work. Please let me know if you encounter bugs or poor documentation. llvm-svn: 112249
2010-08-27 09:01:44 +08:00
}
} InitializeLLVM;
This is a major refactoring of the expression parser. The goal is to separate the parser's data from the data belonging to the parser's clients. This allows clients to use the parser to obtain (for example) a JIT compiled function or some DWARF code, and then discard the parser state. Previously, parser state was held in ClangExpression and used liberally by ClangFunction, which inherited from ClangExpression. The main effects of this refactoring are: - reducing ClangExpression to an abstract class that declares methods that any client must expose to the expression parser, - moving the code specific to implementing the "expr" command from ClangExpression and CommandObjectExpression into ClangUserExpression, a new class, - moving the common parser interaction code from ClangExpression into ClangExpressionParser, a new class, and - making ClangFunction rely only on ClangExpressionParser and not depend on the internal implementation of ClangExpression. Side effects include: - the compiler interaction code has been factored out of ClangFunction and is now in an AST pass (ASTStructExtractor), - the header file for ClangFunction is now fully documented, - several bugs that only popped up when Clang was deallocated (which never happened, since the lifetime of the compiler was essentially infinite) are now fixed, and - the developer-only "call" command has been disabled. I have tested the expr command and the Objective-C step-into code, which use ClangUserExpression and ClangFunction, respectively, and verified that they work. Please let me know if you encounter bugs or poor documentation. llvm-svn: 112249
2010-08-27 09:01:44 +08:00
// 1. Create a new compiler instance.
m_compiler.reset(new CompilerInstance());
// 2. Install the target.
lldb::TargetSP target_sp;
if (exe_scope)
target_sp = exe_scope->CalculateTarget();
// TODO: figure out what to really do when we don't have a valid target.
// Sometimes this will be ok to just use the host target triple (when we
// evaluate say "2+3", but other expressions like breakpoint conditions
// and other things that _are_ target specific really shouldn't just be
// using the host triple. This needs to be fixed in a better way.
if (target_sp && target_sp->GetArchitecture().IsValid())
{
std::string triple = target_sp->GetArchitecture().GetTriple().str();
int dash_count = 0;
for (size_t i = 0; i < triple.size(); ++i)
{
if (triple[i] == '-')
dash_count++;
if (dash_count == 3)
{
triple.resize(i);
break;
}
}
m_compiler->getTargetOpts().Triple = triple;
}
else
{
m_compiler->getTargetOpts().Triple = llvm::sys::getDefaultTargetTriple();
}
if (target_sp->GetArchitecture().GetMachine() == llvm::Triple::x86 ||
target_sp->GetArchitecture().GetMachine() == llvm::Triple::x86_64)
{
m_compiler->getTargetOpts().Features.push_back("+sse");
m_compiler->getTargetOpts().Features.push_back("+sse2");
}
if (m_compiler->getTargetOpts().Triple.find("ios") != std::string::npos)
m_compiler->getTargetOpts().ABI = "apcs-gnu";
m_compiler->createDiagnostics();
// Create the target instance.
m_compiler->setTarget(TargetInfo::CreateTargetInfo(m_compiler->getDiagnostics(),
&m_compiler->getTargetOpts()));
assert (m_compiler->hasTarget());
// 3. Set options.
This is a major refactoring of the expression parser. The goal is to separate the parser's data from the data belonging to the parser's clients. This allows clients to use the parser to obtain (for example) a JIT compiled function or some DWARF code, and then discard the parser state. Previously, parser state was held in ClangExpression and used liberally by ClangFunction, which inherited from ClangExpression. The main effects of this refactoring are: - reducing ClangExpression to an abstract class that declares methods that any client must expose to the expression parser, - moving the code specific to implementing the "expr" command from ClangExpression and CommandObjectExpression into ClangUserExpression, a new class, - moving the common parser interaction code from ClangExpression into ClangExpressionParser, a new class, and - making ClangFunction rely only on ClangExpressionParser and not depend on the internal implementation of ClangExpression. Side effects include: - the compiler interaction code has been factored out of ClangFunction and is now in an AST pass (ASTStructExtractor), - the header file for ClangFunction is now fully documented, - several bugs that only popped up when Clang was deallocated (which never happened, since the lifetime of the compiler was essentially infinite) are now fixed, and - the developer-only "call" command has been disabled. I have tested the expr command and the Objective-C step-into code, which use ClangUserExpression and ClangFunction, respectively, and verified that they work. Please let me know if you encounter bugs or poor documentation. llvm-svn: 112249
2010-08-27 09:01:44 +08:00
lldb::LanguageType language = expr.Language();
switch (language)
{
case lldb::eLanguageTypeC:
break;
case lldb::eLanguageTypeObjC:
m_compiler->getLangOpts().ObjC1 = true;
m_compiler->getLangOpts().ObjC2 = true;
break;
case lldb::eLanguageTypeC_plus_plus:
m_compiler->getLangOpts().CPlusPlus = true;
m_compiler->getLangOpts().CPlusPlus11 = true;
break;
case lldb::eLanguageTypeObjC_plus_plus:
default:
m_compiler->getLangOpts().ObjC1 = true;
m_compiler->getLangOpts().ObjC2 = true;
m_compiler->getLangOpts().CPlusPlus = true;
m_compiler->getLangOpts().CPlusPlus11 = true;
break;
}
m_compiler->getLangOpts().Bool = true;
m_compiler->getLangOpts().WChar = true;
m_compiler->getLangOpts().Blocks = true;
m_compiler->getLangOpts().DebuggerSupport = true; // Features specifically for debugger clients
if (expr.DesiredResultType() == ClangExpression::eResultTypeId)
m_compiler->getLangOpts().DebuggerCastResultToId = true;
// Spell checking is a nice feature, but it ends up completing a
// lot of types that we didn't strictly speaking need to complete.
// As a result, we spend a long time parsing and importing debug
// information.
m_compiler->getLangOpts().SpellChecking = false;
lldb::ProcessSP process_sp;
if (exe_scope)
process_sp = exe_scope->CalculateProcess();
if (process_sp && m_compiler->getLangOpts().ObjC1)
{
if (process_sp->GetObjCLanguageRuntime())
{
if (process_sp->GetObjCLanguageRuntime()->GetRuntimeVersion() == eAppleObjC_V2)
m_compiler->getLangOpts().ObjCRuntime.set(ObjCRuntime::MacOSX, VersionTuple(10, 7));
else
m_compiler->getLangOpts().ObjCRuntime.set(ObjCRuntime::FragileMacOSX, VersionTuple(10, 7));
if (process_sp->GetObjCLanguageRuntime()->HasNewLiteralsAndIndexing())
m_compiler->getLangOpts().DebuggerObjCLiteral = true;
}
}
This is a major refactoring of the expression parser. The goal is to separate the parser's data from the data belonging to the parser's clients. This allows clients to use the parser to obtain (for example) a JIT compiled function or some DWARF code, and then discard the parser state. Previously, parser state was held in ClangExpression and used liberally by ClangFunction, which inherited from ClangExpression. The main effects of this refactoring are: - reducing ClangExpression to an abstract class that declares methods that any client must expose to the expression parser, - moving the code specific to implementing the "expr" command from ClangExpression and CommandObjectExpression into ClangUserExpression, a new class, - moving the common parser interaction code from ClangExpression into ClangExpressionParser, a new class, and - making ClangFunction rely only on ClangExpressionParser and not depend on the internal implementation of ClangExpression. Side effects include: - the compiler interaction code has been factored out of ClangFunction and is now in an AST pass (ASTStructExtractor), - the header file for ClangFunction is now fully documented, - several bugs that only popped up when Clang was deallocated (which never happened, since the lifetime of the compiler was essentially infinite) are now fixed, and - the developer-only "call" command has been disabled. I have tested the expr command and the Objective-C step-into code, which use ClangUserExpression and ClangFunction, respectively, and verified that they work. Please let me know if you encounter bugs or poor documentation. llvm-svn: 112249
2010-08-27 09:01:44 +08:00
m_compiler->getLangOpts().ThreadsafeStatics = false;
m_compiler->getLangOpts().AccessControl = false; // Debuggers get universal access
m_compiler->getLangOpts().DollarIdents = true; // $ indicates a persistent variable name
This is a major refactoring of the expression parser. The goal is to separate the parser's data from the data belonging to the parser's clients. This allows clients to use the parser to obtain (for example) a JIT compiled function or some DWARF code, and then discard the parser state. Previously, parser state was held in ClangExpression and used liberally by ClangFunction, which inherited from ClangExpression. The main effects of this refactoring are: - reducing ClangExpression to an abstract class that declares methods that any client must expose to the expression parser, - moving the code specific to implementing the "expr" command from ClangExpression and CommandObjectExpression into ClangUserExpression, a new class, - moving the common parser interaction code from ClangExpression into ClangExpressionParser, a new class, and - making ClangFunction rely only on ClangExpressionParser and not depend on the internal implementation of ClangExpression. Side effects include: - the compiler interaction code has been factored out of ClangFunction and is now in an AST pass (ASTStructExtractor), - the header file for ClangFunction is now fully documented, - several bugs that only popped up when Clang was deallocated (which never happened, since the lifetime of the compiler was essentially infinite) are now fixed, and - the developer-only "call" command has been disabled. I have tested the expr command and the Objective-C step-into code, which use ClangUserExpression and ClangFunction, respectively, and verified that they work. Please let me know if you encounter bugs or poor documentation. llvm-svn: 112249
2010-08-27 09:01:44 +08:00
// Set CodeGen options
m_compiler->getCodeGenOpts().EmitDeclMetadata = true;
m_compiler->getCodeGenOpts().InstrumentFunctions = false;
// Disable some warnings.
m_compiler->getDiagnostics().setDiagnosticGroupMapping("unused-value", clang::diag::MAP_IGNORE, SourceLocation());
m_compiler->getDiagnostics().setDiagnosticGroupMapping("odr", clang::diag::MAP_IGNORE, SourceLocation());
This is a major refactoring of the expression parser. The goal is to separate the parser's data from the data belonging to the parser's clients. This allows clients to use the parser to obtain (for example) a JIT compiled function or some DWARF code, and then discard the parser state. Previously, parser state was held in ClangExpression and used liberally by ClangFunction, which inherited from ClangExpression. The main effects of this refactoring are: - reducing ClangExpression to an abstract class that declares methods that any client must expose to the expression parser, - moving the code specific to implementing the "expr" command from ClangExpression and CommandObjectExpression into ClangUserExpression, a new class, - moving the common parser interaction code from ClangExpression into ClangExpressionParser, a new class, and - making ClangFunction rely only on ClangExpressionParser and not depend on the internal implementation of ClangExpression. Side effects include: - the compiler interaction code has been factored out of ClangFunction and is now in an AST pass (ASTStructExtractor), - the header file for ClangFunction is now fully documented, - several bugs that only popped up when Clang was deallocated (which never happened, since the lifetime of the compiler was essentially infinite) are now fixed, and - the developer-only "call" command has been disabled. I have tested the expr command and the Objective-C step-into code, which use ClangUserExpression and ClangFunction, respectively, and verified that they work. Please let me know if you encounter bugs or poor documentation. llvm-svn: 112249
2010-08-27 09:01:44 +08:00
// Inform the target of the language options
//
// FIXME: We shouldn't need to do this, the target should be immutable once
// created. This complexity should be lifted elsewhere.
m_compiler->getTarget().setForcedLangOptions(m_compiler->getLangOpts());
// 4. Set up the diagnostic buffer for reporting errors
m_compiler->getDiagnostics().setClient(new clang::TextDiagnosticBuffer);
This is a major refactoring of the expression parser. The goal is to separate the parser's data from the data belonging to the parser's clients. This allows clients to use the parser to obtain (for example) a JIT compiled function or some DWARF code, and then discard the parser state. Previously, parser state was held in ClangExpression and used liberally by ClangFunction, which inherited from ClangExpression. The main effects of this refactoring are: - reducing ClangExpression to an abstract class that declares methods that any client must expose to the expression parser, - moving the code specific to implementing the "expr" command from ClangExpression and CommandObjectExpression into ClangUserExpression, a new class, - moving the common parser interaction code from ClangExpression into ClangExpressionParser, a new class, and - making ClangFunction rely only on ClangExpressionParser and not depend on the internal implementation of ClangExpression. Side effects include: - the compiler interaction code has been factored out of ClangFunction and is now in an AST pass (ASTStructExtractor), - the header file for ClangFunction is now fully documented, - several bugs that only popped up when Clang was deallocated (which never happened, since the lifetime of the compiler was essentially infinite) are now fixed, and - the developer-only "call" command has been disabled. I have tested the expr command and the Objective-C step-into code, which use ClangUserExpression and ClangFunction, respectively, and verified that they work. Please let me know if you encounter bugs or poor documentation. llvm-svn: 112249
2010-08-27 09:01:44 +08:00
// 5. Set up the source management objects inside the compiler
clang::FileSystemOptions file_system_options;
m_file_manager.reset(new clang::FileManager(file_system_options));
This is a major refactoring of the expression parser. The goal is to separate the parser's data from the data belonging to the parser's clients. This allows clients to use the parser to obtain (for example) a JIT compiled function or some DWARF code, and then discard the parser state. Previously, parser state was held in ClangExpression and used liberally by ClangFunction, which inherited from ClangExpression. The main effects of this refactoring are: - reducing ClangExpression to an abstract class that declares methods that any client must expose to the expression parser, - moving the code specific to implementing the "expr" command from ClangExpression and CommandObjectExpression into ClangUserExpression, a new class, - moving the common parser interaction code from ClangExpression into ClangExpressionParser, a new class, and - making ClangFunction rely only on ClangExpressionParser and not depend on the internal implementation of ClangExpression. Side effects include: - the compiler interaction code has been factored out of ClangFunction and is now in an AST pass (ASTStructExtractor), - the header file for ClangFunction is now fully documented, - several bugs that only popped up when Clang was deallocated (which never happened, since the lifetime of the compiler was essentially infinite) are now fixed, and - the developer-only "call" command has been disabled. I have tested the expr command and the Objective-C step-into code, which use ClangUserExpression and ClangFunction, respectively, and verified that they work. Please let me know if you encounter bugs or poor documentation. llvm-svn: 112249
2010-08-27 09:01:44 +08:00
if (!m_compiler->hasSourceManager())
m_compiler->createSourceManager(*m_file_manager.get());
This is a major refactoring of the expression parser. The goal is to separate the parser's data from the data belonging to the parser's clients. This allows clients to use the parser to obtain (for example) a JIT compiled function or some DWARF code, and then discard the parser state. Previously, parser state was held in ClangExpression and used liberally by ClangFunction, which inherited from ClangExpression. The main effects of this refactoring are: - reducing ClangExpression to an abstract class that declares methods that any client must expose to the expression parser, - moving the code specific to implementing the "expr" command from ClangExpression and CommandObjectExpression into ClangUserExpression, a new class, - moving the common parser interaction code from ClangExpression into ClangExpressionParser, a new class, and - making ClangFunction rely only on ClangExpressionParser and not depend on the internal implementation of ClangExpression. Side effects include: - the compiler interaction code has been factored out of ClangFunction and is now in an AST pass (ASTStructExtractor), - the header file for ClangFunction is now fully documented, - several bugs that only popped up when Clang was deallocated (which never happened, since the lifetime of the compiler was essentially infinite) are now fixed, and - the developer-only "call" command has been disabled. I have tested the expr command and the Objective-C step-into code, which use ClangUserExpression and ClangFunction, respectively, and verified that they work. Please let me know if you encounter bugs or poor documentation. llvm-svn: 112249
2010-08-27 09:01:44 +08:00
m_compiler->createFileManager();
m_compiler->createPreprocessor();
// 6. Most of this we get from the CompilerInstance, but we
// also want to give the context an ExternalASTSource.
m_selector_table.reset(new SelectorTable());
m_builtin_context.reset(new Builtin::Context());
This is a major refactoring of the expression parser. The goal is to separate the parser's data from the data belonging to the parser's clients. This allows clients to use the parser to obtain (for example) a JIT compiled function or some DWARF code, and then discard the parser state. Previously, parser state was held in ClangExpression and used liberally by ClangFunction, which inherited from ClangExpression. The main effects of this refactoring are: - reducing ClangExpression to an abstract class that declares methods that any client must expose to the expression parser, - moving the code specific to implementing the "expr" command from ClangExpression and CommandObjectExpression into ClangUserExpression, a new class, - moving the common parser interaction code from ClangExpression into ClangExpressionParser, a new class, and - making ClangFunction rely only on ClangExpressionParser and not depend on the internal implementation of ClangExpression. Side effects include: - the compiler interaction code has been factored out of ClangFunction and is now in an AST pass (ASTStructExtractor), - the header file for ClangFunction is now fully documented, - several bugs that only popped up when Clang was deallocated (which never happened, since the lifetime of the compiler was essentially infinite) are now fixed, and - the developer-only "call" command has been disabled. I have tested the expr command and the Objective-C step-into code, which use ClangUserExpression and ClangFunction, respectively, and verified that they work. Please let me know if you encounter bugs or poor documentation. llvm-svn: 112249
2010-08-27 09:01:44 +08:00
std::unique_ptr<clang::ASTContext> ast_context(new ASTContext(m_compiler->getLangOpts(),
m_compiler->getSourceManager(),
&m_compiler->getTarget(),
m_compiler->getPreprocessor().getIdentifierTable(),
*m_selector_table.get(),
*m_builtin_context.get(),
0));
This is a major refactoring of the expression parser. The goal is to separate the parser's data from the data belonging to the parser's clients. This allows clients to use the parser to obtain (for example) a JIT compiled function or some DWARF code, and then discard the parser state. Previously, parser state was held in ClangExpression and used liberally by ClangFunction, which inherited from ClangExpression. The main effects of this refactoring are: - reducing ClangExpression to an abstract class that declares methods that any client must expose to the expression parser, - moving the code specific to implementing the "expr" command from ClangExpression and CommandObjectExpression into ClangUserExpression, a new class, - moving the common parser interaction code from ClangExpression into ClangExpressionParser, a new class, and - making ClangFunction rely only on ClangExpressionParser and not depend on the internal implementation of ClangExpression. Side effects include: - the compiler interaction code has been factored out of ClangFunction and is now in an AST pass (ASTStructExtractor), - the header file for ClangFunction is now fully documented, - several bugs that only popped up when Clang was deallocated (which never happened, since the lifetime of the compiler was essentially infinite) are now fixed, and - the developer-only "call" command has been disabled. I have tested the expr command and the Objective-C step-into code, which use ClangUserExpression and ClangFunction, respectively, and verified that they work. Please let me know if you encounter bugs or poor documentation. llvm-svn: 112249
2010-08-27 09:01:44 +08:00
ClangExpressionDeclMap *decl_map = m_expr.DeclMap();
if (decl_map)
{
llvm::OwningPtr<clang::ExternalASTSource> ast_source(decl_map->CreateProxy());
decl_map->InstallASTContext(ast_context.get());
This is a major refactoring of the expression parser. The goal is to separate the parser's data from the data belonging to the parser's clients. This allows clients to use the parser to obtain (for example) a JIT compiled function or some DWARF code, and then discard the parser state. Previously, parser state was held in ClangExpression and used liberally by ClangFunction, which inherited from ClangExpression. The main effects of this refactoring are: - reducing ClangExpression to an abstract class that declares methods that any client must expose to the expression parser, - moving the code specific to implementing the "expr" command from ClangExpression and CommandObjectExpression into ClangUserExpression, a new class, - moving the common parser interaction code from ClangExpression into ClangExpressionParser, a new class, and - making ClangFunction rely only on ClangExpressionParser and not depend on the internal implementation of ClangExpression. Side effects include: - the compiler interaction code has been factored out of ClangFunction and is now in an AST pass (ASTStructExtractor), - the header file for ClangFunction is now fully documented, - several bugs that only popped up when Clang was deallocated (which never happened, since the lifetime of the compiler was essentially infinite) are now fixed, and - the developer-only "call" command has been disabled. I have tested the expr command and the Objective-C step-into code, which use ClangUserExpression and ClangFunction, respectively, and verified that they work. Please let me know if you encounter bugs or poor documentation. llvm-svn: 112249
2010-08-27 09:01:44 +08:00
ast_context->setExternalSource(ast_source);
}
m_compiler->setASTContext(ast_context.release());
std::string module_name("$__lldb_module");
This is a major refactoring of the expression parser. The goal is to separate the parser's data from the data belonging to the parser's clients. This allows clients to use the parser to obtain (for example) a JIT compiled function or some DWARF code, and then discard the parser state. Previously, parser state was held in ClangExpression and used liberally by ClangFunction, which inherited from ClangExpression. The main effects of this refactoring are: - reducing ClangExpression to an abstract class that declares methods that any client must expose to the expression parser, - moving the code specific to implementing the "expr" command from ClangExpression and CommandObjectExpression into ClangUserExpression, a new class, - moving the common parser interaction code from ClangExpression into ClangExpressionParser, a new class, and - making ClangFunction rely only on ClangExpressionParser and not depend on the internal implementation of ClangExpression. Side effects include: - the compiler interaction code has been factored out of ClangFunction and is now in an AST pass (ASTStructExtractor), - the header file for ClangFunction is now fully documented, - several bugs that only popped up when Clang was deallocated (which never happened, since the lifetime of the compiler was essentially infinite) are now fixed, and - the developer-only "call" command has been disabled. I have tested the expr command and the Objective-C step-into code, which use ClangUserExpression and ClangFunction, respectively, and verified that they work. Please let me know if you encounter bugs or poor documentation. llvm-svn: 112249
2010-08-27 09:01:44 +08:00
m_llvm_context.reset(new LLVMContext());
This is a major refactoring of the expression parser. The goal is to separate the parser's data from the data belonging to the parser's clients. This allows clients to use the parser to obtain (for example) a JIT compiled function or some DWARF code, and then discard the parser state. Previously, parser state was held in ClangExpression and used liberally by ClangFunction, which inherited from ClangExpression. The main effects of this refactoring are: - reducing ClangExpression to an abstract class that declares methods that any client must expose to the expression parser, - moving the code specific to implementing the "expr" command from ClangExpression and CommandObjectExpression into ClangUserExpression, a new class, - moving the common parser interaction code from ClangExpression into ClangExpressionParser, a new class, and - making ClangFunction rely only on ClangExpressionParser and not depend on the internal implementation of ClangExpression. Side effects include: - the compiler interaction code has been factored out of ClangFunction and is now in an AST pass (ASTStructExtractor), - the header file for ClangFunction is now fully documented, - several bugs that only popped up when Clang was deallocated (which never happened, since the lifetime of the compiler was essentially infinite) are now fixed, and - the developer-only "call" command has been disabled. I have tested the expr command and the Objective-C step-into code, which use ClangUserExpression and ClangFunction, respectively, and verified that they work. Please let me know if you encounter bugs or poor documentation. llvm-svn: 112249
2010-08-27 09:01:44 +08:00
m_code_generator.reset(CreateLLVMCodeGen(m_compiler->getDiagnostics(),
module_name,
m_compiler->getCodeGenOpts(),
m_compiler->getTargetOpts(),
*m_llvm_context));
This is a major refactoring of the expression parser. The goal is to separate the parser's data from the data belonging to the parser's clients. This allows clients to use the parser to obtain (for example) a JIT compiled function or some DWARF code, and then discard the parser state. Previously, parser state was held in ClangExpression and used liberally by ClangFunction, which inherited from ClangExpression. The main effects of this refactoring are: - reducing ClangExpression to an abstract class that declares methods that any client must expose to the expression parser, - moving the code specific to implementing the "expr" command from ClangExpression and CommandObjectExpression into ClangUserExpression, a new class, - moving the common parser interaction code from ClangExpression into ClangExpressionParser, a new class, and - making ClangFunction rely only on ClangExpressionParser and not depend on the internal implementation of ClangExpression. Side effects include: - the compiler interaction code has been factored out of ClangFunction and is now in an AST pass (ASTStructExtractor), - the header file for ClangFunction is now fully documented, - several bugs that only popped up when Clang was deallocated (which never happened, since the lifetime of the compiler was essentially infinite) are now fixed, and - the developer-only "call" command has been disabled. I have tested the expr command and the Objective-C step-into code, which use ClangUserExpression and ClangFunction, respectively, and verified that they work. Please let me know if you encounter bugs or poor documentation. llvm-svn: 112249
2010-08-27 09:01:44 +08:00
}
ClangExpressionParser::~ClangExpressionParser()
{
}
unsigned
ClangExpressionParser::Parse (Stream &stream)
{
TextDiagnosticBuffer *diag_buf = static_cast<TextDiagnosticBuffer*>(m_compiler->getDiagnostics().getClient());
diag_buf->FlushDiagnostics (m_compiler->getDiagnostics());
This is a major refactoring of the expression parser. The goal is to separate the parser's data from the data belonging to the parser's clients. This allows clients to use the parser to obtain (for example) a JIT compiled function or some DWARF code, and then discard the parser state. Previously, parser state was held in ClangExpression and used liberally by ClangFunction, which inherited from ClangExpression. The main effects of this refactoring are: - reducing ClangExpression to an abstract class that declares methods that any client must expose to the expression parser, - moving the code specific to implementing the "expr" command from ClangExpression and CommandObjectExpression into ClangUserExpression, a new class, - moving the common parser interaction code from ClangExpression into ClangExpressionParser, a new class, and - making ClangFunction rely only on ClangExpressionParser and not depend on the internal implementation of ClangExpression. Side effects include: - the compiler interaction code has been factored out of ClangFunction and is now in an AST pass (ASTStructExtractor), - the header file for ClangFunction is now fully documented, - several bugs that only popped up when Clang was deallocated (which never happened, since the lifetime of the compiler was essentially infinite) are now fixed, and - the developer-only "call" command has been disabled. I have tested the expr command and the Objective-C step-into code, which use ClangUserExpression and ClangFunction, respectively, and verified that they work. Please let me know if you encounter bugs or poor documentation. llvm-svn: 112249
2010-08-27 09:01:44 +08:00
MemoryBuffer *memory_buffer = MemoryBuffer::getMemBufferCopy(m_expr.Text(), __FUNCTION__);
m_compiler->getSourceManager().createMainFileIDForMemBuffer (memory_buffer);
This is a major refactoring of the expression parser. The goal is to separate the parser's data from the data belonging to the parser's clients. This allows clients to use the parser to obtain (for example) a JIT compiled function or some DWARF code, and then discard the parser state. Previously, parser state was held in ClangExpression and used liberally by ClangFunction, which inherited from ClangExpression. The main effects of this refactoring are: - reducing ClangExpression to an abstract class that declares methods that any client must expose to the expression parser, - moving the code specific to implementing the "expr" command from ClangExpression and CommandObjectExpression into ClangUserExpression, a new class, - moving the common parser interaction code from ClangExpression into ClangExpressionParser, a new class, and - making ClangFunction rely only on ClangExpressionParser and not depend on the internal implementation of ClangExpression. Side effects include: - the compiler interaction code has been factored out of ClangFunction and is now in an AST pass (ASTStructExtractor), - the header file for ClangFunction is now fully documented, - several bugs that only popped up when Clang was deallocated (which never happened, since the lifetime of the compiler was essentially infinite) are now fixed, and - the developer-only "call" command has been disabled. I have tested the expr command and the Objective-C step-into code, which use ClangUserExpression and ClangFunction, respectively, and verified that they work. Please let me know if you encounter bugs or poor documentation. llvm-svn: 112249
2010-08-27 09:01:44 +08:00
diag_buf->BeginSourceFile(m_compiler->getLangOpts(), &m_compiler->getPreprocessor());
This is a major refactoring of the expression parser. The goal is to separate the parser's data from the data belonging to the parser's clients. This allows clients to use the parser to obtain (for example) a JIT compiled function or some DWARF code, and then discard the parser state. Previously, parser state was held in ClangExpression and used liberally by ClangFunction, which inherited from ClangExpression. The main effects of this refactoring are: - reducing ClangExpression to an abstract class that declares methods that any client must expose to the expression parser, - moving the code specific to implementing the "expr" command from ClangExpression and CommandObjectExpression into ClangUserExpression, a new class, - moving the common parser interaction code from ClangExpression into ClangExpressionParser, a new class, and - making ClangFunction rely only on ClangExpressionParser and not depend on the internal implementation of ClangExpression. Side effects include: - the compiler interaction code has been factored out of ClangFunction and is now in an AST pass (ASTStructExtractor), - the header file for ClangFunction is now fully documented, - several bugs that only popped up when Clang was deallocated (which never happened, since the lifetime of the compiler was essentially infinite) are now fixed, and - the developer-only "call" command has been disabled. I have tested the expr command and the Objective-C step-into code, which use ClangUserExpression and ClangFunction, respectively, and verified that they work. Please let me know if you encounter bugs or poor documentation. llvm-svn: 112249
2010-08-27 09:01:44 +08:00
ASTConsumer *ast_transformer = m_expr.ASTTransformer(m_code_generator.get());
if (ast_transformer)
ParseAST(m_compiler->getPreprocessor(), ast_transformer, m_compiler->getASTContext());
else
ParseAST(m_compiler->getPreprocessor(), m_code_generator.get(), m_compiler->getASTContext());
diag_buf->EndSourceFile();
This is a major refactoring of the expression parser. The goal is to separate the parser's data from the data belonging to the parser's clients. This allows clients to use the parser to obtain (for example) a JIT compiled function or some DWARF code, and then discard the parser state. Previously, parser state was held in ClangExpression and used liberally by ClangFunction, which inherited from ClangExpression. The main effects of this refactoring are: - reducing ClangExpression to an abstract class that declares methods that any client must expose to the expression parser, - moving the code specific to implementing the "expr" command from ClangExpression and CommandObjectExpression into ClangUserExpression, a new class, - moving the common parser interaction code from ClangExpression into ClangExpressionParser, a new class, and - making ClangFunction rely only on ClangExpressionParser and not depend on the internal implementation of ClangExpression. Side effects include: - the compiler interaction code has been factored out of ClangFunction and is now in an AST pass (ASTStructExtractor), - the header file for ClangFunction is now fully documented, - several bugs that only popped up when Clang was deallocated (which never happened, since the lifetime of the compiler was essentially infinite) are now fixed, and - the developer-only "call" command has been disabled. I have tested the expr command and the Objective-C step-into code, which use ClangUserExpression and ClangFunction, respectively, and verified that they work. Please let me know if you encounter bugs or poor documentation. llvm-svn: 112249
2010-08-27 09:01:44 +08:00
TextDiagnosticBuffer::const_iterator diag_iterator;
int num_errors = 0;
for (diag_iterator = diag_buf->warn_begin();
diag_iterator != diag_buf->warn_end();
This is a major refactoring of the expression parser. The goal is to separate the parser's data from the data belonging to the parser's clients. This allows clients to use the parser to obtain (for example) a JIT compiled function or some DWARF code, and then discard the parser state. Previously, parser state was held in ClangExpression and used liberally by ClangFunction, which inherited from ClangExpression. The main effects of this refactoring are: - reducing ClangExpression to an abstract class that declares methods that any client must expose to the expression parser, - moving the code specific to implementing the "expr" command from ClangExpression and CommandObjectExpression into ClangUserExpression, a new class, - moving the common parser interaction code from ClangExpression into ClangExpressionParser, a new class, and - making ClangFunction rely only on ClangExpressionParser and not depend on the internal implementation of ClangExpression. Side effects include: - the compiler interaction code has been factored out of ClangFunction and is now in an AST pass (ASTStructExtractor), - the header file for ClangFunction is now fully documented, - several bugs that only popped up when Clang was deallocated (which never happened, since the lifetime of the compiler was essentially infinite) are now fixed, and - the developer-only "call" command has been disabled. I have tested the expr command and the Objective-C step-into code, which use ClangUserExpression and ClangFunction, respectively, and verified that they work. Please let me know if you encounter bugs or poor documentation. llvm-svn: 112249
2010-08-27 09:01:44 +08:00
++diag_iterator)
stream.Printf("warning: %s\n", (*diag_iterator).second.c_str());
num_errors = 0;
for (diag_iterator = diag_buf->err_begin();
diag_iterator != diag_buf->err_end();
This is a major refactoring of the expression parser. The goal is to separate the parser's data from the data belonging to the parser's clients. This allows clients to use the parser to obtain (for example) a JIT compiled function or some DWARF code, and then discard the parser state. Previously, parser state was held in ClangExpression and used liberally by ClangFunction, which inherited from ClangExpression. The main effects of this refactoring are: - reducing ClangExpression to an abstract class that declares methods that any client must expose to the expression parser, - moving the code specific to implementing the "expr" command from ClangExpression and CommandObjectExpression into ClangUserExpression, a new class, - moving the common parser interaction code from ClangExpression into ClangExpressionParser, a new class, and - making ClangFunction rely only on ClangExpressionParser and not depend on the internal implementation of ClangExpression. Side effects include: - the compiler interaction code has been factored out of ClangFunction and is now in an AST pass (ASTStructExtractor), - the header file for ClangFunction is now fully documented, - several bugs that only popped up when Clang was deallocated (which never happened, since the lifetime of the compiler was essentially infinite) are now fixed, and - the developer-only "call" command has been disabled. I have tested the expr command and the Objective-C step-into code, which use ClangUserExpression and ClangFunction, respectively, and verified that they work. Please let me know if you encounter bugs or poor documentation. llvm-svn: 112249
2010-08-27 09:01:44 +08:00
++diag_iterator)
{
num_errors++;
stream.Printf("error: %s\n", (*diag_iterator).second.c_str());
}
for (diag_iterator = diag_buf->note_begin();
diag_iterator != diag_buf->note_end();
++diag_iterator)
stream.Printf("note: %s\n", (*diag_iterator).second.c_str());
if (!num_errors)
{
if (m_expr.DeclMap() && !m_expr.DeclMap()->ResolveUnknownTypes())
{
stream.Printf("error: Couldn't infer the type of a variable\n");
num_errors++;
}
}
This is a major refactoring of the expression parser. The goal is to separate the parser's data from the data belonging to the parser's clients. This allows clients to use the parser to obtain (for example) a JIT compiled function or some DWARF code, and then discard the parser state. Previously, parser state was held in ClangExpression and used liberally by ClangFunction, which inherited from ClangExpression. The main effects of this refactoring are: - reducing ClangExpression to an abstract class that declares methods that any client must expose to the expression parser, - moving the code specific to implementing the "expr" command from ClangExpression and CommandObjectExpression into ClangUserExpression, a new class, - moving the common parser interaction code from ClangExpression into ClangExpressionParser, a new class, and - making ClangFunction rely only on ClangExpressionParser and not depend on the internal implementation of ClangExpression. Side effects include: - the compiler interaction code has been factored out of ClangFunction and is now in an AST pass (ASTStructExtractor), - the header file for ClangFunction is now fully documented, - several bugs that only popped up when Clang was deallocated (which never happened, since the lifetime of the compiler was essentially infinite) are now fixed, and - the developer-only "call" command has been disabled. I have tested the expr command and the Objective-C step-into code, which use ClangUserExpression and ClangFunction, respectively, and verified that they work. Please let me know if you encounter bugs or poor documentation. llvm-svn: 112249
2010-08-27 09:01:44 +08:00
return num_errors;
}
static bool FindFunctionInModule (ConstString &mangled_name,
Removed the hacky "#define this ___clang_this" handler for C++ classes. Replaced it with a less hacky approach: - If an expression is defined in the context of a method of class A, then that expression is wrapped as ___clang_class::___clang_expr(void*) { ... } instead of ___clang_expr(void*) { ... }. - ___clang_class is resolved as the type of the target of the "this" pointer in the method the expression is defined in. - When reporting the type of ___clang_class, a method with the signature ___clang_expr(void*) is added to that class, so that Clang doesn't complain about a method being defined without a corresponding declaration. - Whenever the expression gets called, "this" gets looked up, type-checked, and then passed in as the first argument. This required the following changes: - The ABIs were changed to support passing of the "this" pointer as part of trivial calls. - ThreadPlanCallFunction and ClangFunction were changed to support passing of an optional "this" pointer. - ClangUserExpression was extended to perform the wrapping described above. - ClangASTSource was changed to revert the changes required by the hack. - ClangExpressionParser, IRForTarget, and ClangExpressionDeclMap were changed to handle different manglings of ___clang_expr flexibly. This meant no longer searching for a function called ___clang_expr, but rather looking for a function whose name *contains* ___clang_expr. - ClangExpressionParser and ClangExpressionDeclMap now remember whether "this" is required, and know how to look it up as necessary. A few inheritance bugs remain, and I'm trying to resolve these. But it is now possible to use "this" as well as refer implicitly to member variables, when in the proper context. llvm-svn: 114384
2010-09-21 08:44:12 +08:00
llvm::Module *module,
const char *orig_name)
{
for (llvm::Module::iterator fi = module->getFunctionList().begin(), fe = module->getFunctionList().end();
fi != fe;
++fi)
{
if (fi->getName().str().find(orig_name) != std::string::npos)
{
mangled_name.SetCString(fi->getName().str().c_str());
Removed the hacky "#define this ___clang_this" handler for C++ classes. Replaced it with a less hacky approach: - If an expression is defined in the context of a method of class A, then that expression is wrapped as ___clang_class::___clang_expr(void*) { ... } instead of ___clang_expr(void*) { ... }. - ___clang_class is resolved as the type of the target of the "this" pointer in the method the expression is defined in. - When reporting the type of ___clang_class, a method with the signature ___clang_expr(void*) is added to that class, so that Clang doesn't complain about a method being defined without a corresponding declaration. - Whenever the expression gets called, "this" gets looked up, type-checked, and then passed in as the first argument. This required the following changes: - The ABIs were changed to support passing of the "this" pointer as part of trivial calls. - ThreadPlanCallFunction and ClangFunction were changed to support passing of an optional "this" pointer. - ClangUserExpression was extended to perform the wrapping described above. - ClangASTSource was changed to revert the changes required by the hack. - ClangExpressionParser, IRForTarget, and ClangExpressionDeclMap were changed to handle different manglings of ___clang_expr flexibly. This meant no longer searching for a function called ___clang_expr, but rather looking for a function whose name *contains* ___clang_expr. - ClangExpressionParser and ClangExpressionDeclMap now remember whether "this" is required, and know how to look it up as necessary. A few inheritance bugs remain, and I'm trying to resolve these. But it is now possible to use "this" as well as refer implicitly to member variables, when in the proper context. llvm-svn: 114384
2010-09-21 08:44:12 +08:00
return true;
}
}
return false;
}
This is a major refactoring of the expression parser. The goal is to separate the parser's data from the data belonging to the parser's clients. This allows clients to use the parser to obtain (for example) a JIT compiled function or some DWARF code, and then discard the parser state. Previously, parser state was held in ClangExpression and used liberally by ClangFunction, which inherited from ClangExpression. The main effects of this refactoring are: - reducing ClangExpression to an abstract class that declares methods that any client must expose to the expression parser, - moving the code specific to implementing the "expr" command from ClangExpression and CommandObjectExpression into ClangUserExpression, a new class, - moving the common parser interaction code from ClangExpression into ClangExpressionParser, a new class, and - making ClangFunction rely only on ClangExpressionParser and not depend on the internal implementation of ClangExpression. Side effects include: - the compiler interaction code has been factored out of ClangFunction and is now in an AST pass (ASTStructExtractor), - the header file for ClangFunction is now fully documented, - several bugs that only popped up when Clang was deallocated (which never happened, since the lifetime of the compiler was essentially infinite) are now fixed, and - the developer-only "call" command has been disabled. I have tested the expr command and the Objective-C step-into code, which use ClangUserExpression and ClangFunction, respectively, and verified that they work. Please let me know if you encounter bugs or poor documentation. llvm-svn: 112249
2010-08-27 09:01:44 +08:00
Error
ClangExpressionParser::PrepareForExecution (lldb::addr_t &func_addr,
lldb::addr_t &func_end,
std::unique_ptr<IRExecutionUnit> &execution_unit_ap,
This patch modifies the expression parser to allow it to execute expressions even in the absence of a process. This allows expressions to run in situations where the target cannot run -- e.g., to perform calculations based on type information, or to inspect a binary's static data. This modification touches the following files: lldb-private-enumerations.h Introduce a new enum specifying the policy for processing an expression. Some expressions should always be JITted, for example if they are functions that will be used over and over again. Some expressions should always be interpreted, for example if the target is unsafe to run. For most, it is acceptable to JIT them, but interpretation is preferable when possible. Target.[h,cpp] Have EvaluateExpression now accept the new enum. ClangExpressionDeclMap.[cpp,h] Add support for the IR interpreter and also make the ClangExpressionDeclMap more robust in the absence of a process. ClangFunction.[cpp,h] Add support for the new enum. IRInterpreter.[cpp,h] New implementation. ClangUserExpression.[cpp,h] Add support for the new enum, and for running expressions in the absence of a process. ClangExpression.h Remove references to the old DWARF-based method of evaluating expressions, because it has been superseded for now. ClangUtilityFunction.[cpp,h] Add support for the new enum. ClangExpressionParser.[cpp,h] Add support for the new enum, remove references to DWARF, and add support for checking whether the expression could be evaluated statically. IRForTarget.[h,cpp] Add support for the new enum, and add utility functions to support the interpreter. IRToDWARF.cpp Removed CommandObjectExpression.cpp Remove references to the obsolete -i option. Process.cpp Modify calls to ClangUserExpression::Evaluate to pass the correct enum (for dlopen/dlclose) SBValue.cpp Add support for the new enum. SBFrame.cpp Add support for he new enum. BreakpointOptions.cpp Add support for the new enum. llvm-svn: 139772
2011-09-15 10:13:07 +08:00
ExecutionContext &exe_ctx,
This commit changes the way LLDB executes user expressions. Previously, ClangUserExpression assumed that if there was a constant result for an expression then it could be determined during parsing. In particular, the IRInterpreter ran while parser state (in particular, ClangExpressionDeclMap) was present. This approach is flawed, because the IRInterpreter actually is capable of using external variables, and hence the result might be different each run. Until now, we papered over this flaw by re-parsing the expression each time we ran it. I have rewritten the IRInterpreter to be completely independent of the ClangExpressionDeclMap. Instead of special-casing external variable lookup, which ties the IRInterpreter closely to LLDB, we now interpret the exact same IR that the JIT would see. This IR assumes that materialization has occurred; hence the recent implementation of the Materializer, which does not require parser state (in the form of ClangExpressionDeclMap) to be present. Materialization, interpretation, and dematerialization are now all independent of parsing. This means that in theory we can parse expressions once and run them many times. I have three outstanding tasks before shutting this down: - First, I will ensure that all of this works with core files. Core files have a Process but do not allow allocating memory, which currently confuses materialization. - Second, I will make expression breakpoint conditions remember their ClangUserExpression and re-use it. - Third, I will tear out all the redundant code (for example, materialization logic in ClangExpressionDeclMap) that is no longer used. While implementing this fix, I also found a bug in IRForTarget's handling of floating-point constants. This should be fixed. llvm-svn: 179801
2013-04-19 06:06:33 +08:00
bool &can_interpret,
This patch modifies the expression parser to allow it to execute expressions even in the absence of a process. This allows expressions to run in situations where the target cannot run -- e.g., to perform calculations based on type information, or to inspect a binary's static data. This modification touches the following files: lldb-private-enumerations.h Introduce a new enum specifying the policy for processing an expression. Some expressions should always be JITted, for example if they are functions that will be used over and over again. Some expressions should always be interpreted, for example if the target is unsafe to run. For most, it is acceptable to JIT them, but interpretation is preferable when possible. Target.[h,cpp] Have EvaluateExpression now accept the new enum. ClangExpressionDeclMap.[cpp,h] Add support for the IR interpreter and also make the ClangExpressionDeclMap more robust in the absence of a process. ClangFunction.[cpp,h] Add support for the new enum. IRInterpreter.[cpp,h] New implementation. ClangUserExpression.[cpp,h] Add support for the new enum, and for running expressions in the absence of a process. ClangExpression.h Remove references to the old DWARF-based method of evaluating expressions, because it has been superseded for now. ClangUtilityFunction.[cpp,h] Add support for the new enum. ClangExpressionParser.[cpp,h] Add support for the new enum, remove references to DWARF, and add support for checking whether the expression could be evaluated statically. IRForTarget.[h,cpp] Add support for the new enum, and add utility functions to support the interpreter. IRToDWARF.cpp Removed CommandObjectExpression.cpp Remove references to the obsolete -i option. Process.cpp Modify calls to ClangUserExpression::Evaluate to pass the correct enum (for dlopen/dlclose) SBValue.cpp Add support for the new enum. SBFrame.cpp Add support for he new enum. BreakpointOptions.cpp Add support for the new enum. llvm-svn: 139772
2011-09-15 10:13:07 +08:00
ExecutionPolicy execution_policy)
This is a major refactoring of the expression parser. The goal is to separate the parser's data from the data belonging to the parser's clients. This allows clients to use the parser to obtain (for example) a JIT compiled function or some DWARF code, and then discard the parser state. Previously, parser state was held in ClangExpression and used liberally by ClangFunction, which inherited from ClangExpression. The main effects of this refactoring are: - reducing ClangExpression to an abstract class that declares methods that any client must expose to the expression parser, - moving the code specific to implementing the "expr" command from ClangExpression and CommandObjectExpression into ClangUserExpression, a new class, - moving the common parser interaction code from ClangExpression into ClangExpressionParser, a new class, and - making ClangFunction rely only on ClangExpressionParser and not depend on the internal implementation of ClangExpression. Side effects include: - the compiler interaction code has been factored out of ClangFunction and is now in an AST pass (ASTStructExtractor), - the header file for ClangFunction is now fully documented, - several bugs that only popped up when Clang was deallocated (which never happened, since the lifetime of the compiler was essentially infinite) are now fixed, and - the developer-only "call" command has been disabled. I have tested the expr command and the Objective-C step-into code, which use ClangUserExpression and ClangFunction, respectively, and verified that they work. Please let me know if you encounter bugs or poor documentation. llvm-svn: 112249
2010-08-27 09:01:44 +08:00
{
func_addr = LLDB_INVALID_ADDRESS;
func_end = LLDB_INVALID_ADDRESS;
Log *log(lldb_private::GetLogIfAllCategoriesSet (LIBLLDB_LOG_EXPRESSIONS));
Removed the hacky "#define this ___clang_this" handler for C++ classes. Replaced it with a less hacky approach: - If an expression is defined in the context of a method of class A, then that expression is wrapped as ___clang_class::___clang_expr(void*) { ... } instead of ___clang_expr(void*) { ... }. - ___clang_class is resolved as the type of the target of the "this" pointer in the method the expression is defined in. - When reporting the type of ___clang_class, a method with the signature ___clang_expr(void*) is added to that class, so that Clang doesn't complain about a method being defined without a corresponding declaration. - Whenever the expression gets called, "this" gets looked up, type-checked, and then passed in as the first argument. This required the following changes: - The ABIs were changed to support passing of the "this" pointer as part of trivial calls. - ThreadPlanCallFunction and ClangFunction were changed to support passing of an optional "this" pointer. - ClangUserExpression was extended to perform the wrapping described above. - ClangASTSource was changed to revert the changes required by the hack. - ClangExpressionParser, IRForTarget, and ClangExpressionDeclMap were changed to handle different manglings of ___clang_expr flexibly. This meant no longer searching for a function called ___clang_expr, but rather looking for a function whose name *contains* ___clang_expr. - ClangExpressionParser and ClangExpressionDeclMap now remember whether "this" is required, and know how to look it up as necessary. A few inheritance bugs remain, and I'm trying to resolve these. But it is now possible to use "this" as well as refer implicitly to member variables, when in the proper context. llvm-svn: 114384
2010-09-21 08:44:12 +08:00
std::unique_ptr<llvm::ExecutionEngine> execution_engine_ap;
This is a major refactoring of the expression parser. The goal is to separate the parser's data from the data belonging to the parser's clients. This allows clients to use the parser to obtain (for example) a JIT compiled function or some DWARF code, and then discard the parser state. Previously, parser state was held in ClangExpression and used liberally by ClangFunction, which inherited from ClangExpression. The main effects of this refactoring are: - reducing ClangExpression to an abstract class that declares methods that any client must expose to the expression parser, - moving the code specific to implementing the "expr" command from ClangExpression and CommandObjectExpression into ClangUserExpression, a new class, - moving the common parser interaction code from ClangExpression into ClangExpressionParser, a new class, and - making ClangFunction rely only on ClangExpressionParser and not depend on the internal implementation of ClangExpression. Side effects include: - the compiler interaction code has been factored out of ClangFunction and is now in an AST pass (ASTStructExtractor), - the header file for ClangFunction is now fully documented, - several bugs that only popped up when Clang was deallocated (which never happened, since the lifetime of the compiler was essentially infinite) are now fixed, and - the developer-only "call" command has been disabled. I have tested the expr command and the Objective-C step-into code, which use ClangUserExpression and ClangFunction, respectively, and verified that they work. Please let me know if you encounter bugs or poor documentation. llvm-svn: 112249
2010-08-27 09:01:44 +08:00
Error err;
std::unique_ptr<llvm::Module> module_ap (m_code_generator->ReleaseModule());
This is a major refactoring of the expression parser. The goal is to separate the parser's data from the data belonging to the parser's clients. This allows clients to use the parser to obtain (for example) a JIT compiled function or some DWARF code, and then discard the parser state. Previously, parser state was held in ClangExpression and used liberally by ClangFunction, which inherited from ClangExpression. The main effects of this refactoring are: - reducing ClangExpression to an abstract class that declares methods that any client must expose to the expression parser, - moving the code specific to implementing the "expr" command from ClangExpression and CommandObjectExpression into ClangUserExpression, a new class, - moving the common parser interaction code from ClangExpression into ClangExpressionParser, a new class, and - making ClangFunction rely only on ClangExpressionParser and not depend on the internal implementation of ClangExpression. Side effects include: - the compiler interaction code has been factored out of ClangFunction and is now in an AST pass (ASTStructExtractor), - the header file for ClangFunction is now fully documented, - several bugs that only popped up when Clang was deallocated (which never happened, since the lifetime of the compiler was essentially infinite) are now fixed, and - the developer-only "call" command has been disabled. I have tested the expr command and the Objective-C step-into code, which use ClangUserExpression and ClangFunction, respectively, and verified that they work. Please let me know if you encounter bugs or poor documentation. llvm-svn: 112249
2010-08-27 09:01:44 +08:00
if (!module_ap.get())
This is a major refactoring of the expression parser. The goal is to separate the parser's data from the data belonging to the parser's clients. This allows clients to use the parser to obtain (for example) a JIT compiled function or some DWARF code, and then discard the parser state. Previously, parser state was held in ClangExpression and used liberally by ClangFunction, which inherited from ClangExpression. The main effects of this refactoring are: - reducing ClangExpression to an abstract class that declares methods that any client must expose to the expression parser, - moving the code specific to implementing the "expr" command from ClangExpression and CommandObjectExpression into ClangUserExpression, a new class, - moving the common parser interaction code from ClangExpression into ClangExpressionParser, a new class, and - making ClangFunction rely only on ClangExpressionParser and not depend on the internal implementation of ClangExpression. Side effects include: - the compiler interaction code has been factored out of ClangFunction and is now in an AST pass (ASTStructExtractor), - the header file for ClangFunction is now fully documented, - several bugs that only popped up when Clang was deallocated (which never happened, since the lifetime of the compiler was essentially infinite) are now fixed, and - the developer-only "call" command has been disabled. I have tested the expr command and the Objective-C step-into code, which use ClangUserExpression and ClangFunction, respectively, and verified that they work. Please let me know if you encounter bugs or poor documentation. llvm-svn: 112249
2010-08-27 09:01:44 +08:00
{
err.SetErrorToGenericError();
err.SetErrorString("IR doesn't contain a module");
return err;
}
Removed the hacky "#define this ___clang_this" handler for C++ classes. Replaced it with a less hacky approach: - If an expression is defined in the context of a method of class A, then that expression is wrapped as ___clang_class::___clang_expr(void*) { ... } instead of ___clang_expr(void*) { ... }. - ___clang_class is resolved as the type of the target of the "this" pointer in the method the expression is defined in. - When reporting the type of ___clang_class, a method with the signature ___clang_expr(void*) is added to that class, so that Clang doesn't complain about a method being defined without a corresponding declaration. - Whenever the expression gets called, "this" gets looked up, type-checked, and then passed in as the first argument. This required the following changes: - The ABIs were changed to support passing of the "this" pointer as part of trivial calls. - ThreadPlanCallFunction and ClangFunction were changed to support passing of an optional "this" pointer. - ClangUserExpression was extended to perform the wrapping described above. - ClangASTSource was changed to revert the changes required by the hack. - ClangExpressionParser, IRForTarget, and ClangExpressionDeclMap were changed to handle different manglings of ___clang_expr flexibly. This meant no longer searching for a function called ___clang_expr, but rather looking for a function whose name *contains* ___clang_expr. - ClangExpressionParser and ClangExpressionDeclMap now remember whether "this" is required, and know how to look it up as necessary. A few inheritance bugs remain, and I'm trying to resolve these. But it is now possible to use "this" as well as refer implicitly to member variables, when in the proper context. llvm-svn: 114384
2010-09-21 08:44:12 +08:00
// Find the actual name of the function (it's often mangled somehow)
ConstString function_name;
Removed the hacky "#define this ___clang_this" handler for C++ classes. Replaced it with a less hacky approach: - If an expression is defined in the context of a method of class A, then that expression is wrapped as ___clang_class::___clang_expr(void*) { ... } instead of ___clang_expr(void*) { ... }. - ___clang_class is resolved as the type of the target of the "this" pointer in the method the expression is defined in. - When reporting the type of ___clang_class, a method with the signature ___clang_expr(void*) is added to that class, so that Clang doesn't complain about a method being defined without a corresponding declaration. - Whenever the expression gets called, "this" gets looked up, type-checked, and then passed in as the first argument. This required the following changes: - The ABIs were changed to support passing of the "this" pointer as part of trivial calls. - ThreadPlanCallFunction and ClangFunction were changed to support passing of an optional "this" pointer. - ClangUserExpression was extended to perform the wrapping described above. - ClangASTSource was changed to revert the changes required by the hack. - ClangExpressionParser, IRForTarget, and ClangExpressionDeclMap were changed to handle different manglings of ___clang_expr flexibly. This meant no longer searching for a function called ___clang_expr, but rather looking for a function whose name *contains* ___clang_expr. - ClangExpressionParser and ClangExpressionDeclMap now remember whether "this" is required, and know how to look it up as necessary. A few inheritance bugs remain, and I'm trying to resolve these. But it is now possible to use "this" as well as refer implicitly to member variables, when in the proper context. llvm-svn: 114384
2010-09-21 08:44:12 +08:00
if (!FindFunctionInModule(function_name, module_ap.get(), m_expr.FunctionName()))
Removed the hacky "#define this ___clang_this" handler for C++ classes. Replaced it with a less hacky approach: - If an expression is defined in the context of a method of class A, then that expression is wrapped as ___clang_class::___clang_expr(void*) { ... } instead of ___clang_expr(void*) { ... }. - ___clang_class is resolved as the type of the target of the "this" pointer in the method the expression is defined in. - When reporting the type of ___clang_class, a method with the signature ___clang_expr(void*) is added to that class, so that Clang doesn't complain about a method being defined without a corresponding declaration. - Whenever the expression gets called, "this" gets looked up, type-checked, and then passed in as the first argument. This required the following changes: - The ABIs were changed to support passing of the "this" pointer as part of trivial calls. - ThreadPlanCallFunction and ClangFunction were changed to support passing of an optional "this" pointer. - ClangUserExpression was extended to perform the wrapping described above. - ClangASTSource was changed to revert the changes required by the hack. - ClangExpressionParser, IRForTarget, and ClangExpressionDeclMap were changed to handle different manglings of ___clang_expr flexibly. This meant no longer searching for a function called ___clang_expr, but rather looking for a function whose name *contains* ___clang_expr. - ClangExpressionParser and ClangExpressionDeclMap now remember whether "this" is required, and know how to look it up as necessary. A few inheritance bugs remain, and I'm trying to resolve these. But it is now possible to use "this" as well as refer implicitly to member variables, when in the proper context. llvm-svn: 114384
2010-09-21 08:44:12 +08:00
{
err.SetErrorToGenericError();
err.SetErrorStringWithFormat("Couldn't find %s() in the module", m_expr.FunctionName());
return err;
}
else
{
if (log)
log->Printf("Found function %s for %s", function_name.AsCString(), m_expr.FunctionName());
Removed the hacky "#define this ___clang_this" handler for C++ classes. Replaced it with a less hacky approach: - If an expression is defined in the context of a method of class A, then that expression is wrapped as ___clang_class::___clang_expr(void*) { ... } instead of ___clang_expr(void*) { ... }. - ___clang_class is resolved as the type of the target of the "this" pointer in the method the expression is defined in. - When reporting the type of ___clang_class, a method with the signature ___clang_expr(void*) is added to that class, so that Clang doesn't complain about a method being defined without a corresponding declaration. - Whenever the expression gets called, "this" gets looked up, type-checked, and then passed in as the first argument. This required the following changes: - The ABIs were changed to support passing of the "this" pointer as part of trivial calls. - ThreadPlanCallFunction and ClangFunction were changed to support passing of an optional "this" pointer. - ClangUserExpression was extended to perform the wrapping described above. - ClangASTSource was changed to revert the changes required by the hack. - ClangExpressionParser, IRForTarget, and ClangExpressionDeclMap were changed to handle different manglings of ___clang_expr flexibly. This meant no longer searching for a function called ___clang_expr, but rather looking for a function whose name *contains* ___clang_expr. - ClangExpressionParser and ClangExpressionDeclMap now remember whether "this" is required, and know how to look it up as necessary. A few inheritance bugs remain, and I'm trying to resolve these. But it is now possible to use "this" as well as refer implicitly to member variables, when in the proper context. llvm-svn: 114384
2010-09-21 08:44:12 +08:00
}
m_execution_unit.reset(new IRExecutionUnit(m_llvm_context, // handed off here
module_ap, // handed off here
function_name,
exe_ctx.GetTargetSP(),
m_compiler->getTargetOpts().Features));
This is a major refactoring of the expression parser. The goal is to separate the parser's data from the data belonging to the parser's clients. This allows clients to use the parser to obtain (for example) a JIT compiled function or some DWARF code, and then discard the parser state. Previously, parser state was held in ClangExpression and used liberally by ClangFunction, which inherited from ClangExpression. The main effects of this refactoring are: - reducing ClangExpression to an abstract class that declares methods that any client must expose to the expression parser, - moving the code specific to implementing the "expr" command from ClangExpression and CommandObjectExpression into ClangUserExpression, a new class, - moving the common parser interaction code from ClangExpression into ClangExpressionParser, a new class, and - making ClangFunction rely only on ClangExpressionParser and not depend on the internal implementation of ClangExpression. Side effects include: - the compiler interaction code has been factored out of ClangFunction and is now in an AST pass (ASTStructExtractor), - the header file for ClangFunction is now fully documented, - several bugs that only popped up when Clang was deallocated (which never happened, since the lifetime of the compiler was essentially infinite) are now fixed, and - the developer-only "call" command has been disabled. I have tested the expr command and the Objective-C step-into code, which use ClangUserExpression and ClangFunction, respectively, and verified that they work. Please let me know if you encounter bugs or poor documentation. llvm-svn: 112249
2010-08-27 09:01:44 +08:00
ClangExpressionDeclMap *decl_map = m_expr.DeclMap(); // result can be NULL
if (decl_map)
{
Stream *error_stream = NULL;
Target *target = exe_ctx.GetTargetPtr();
if (target)
error_stream = &target->GetDebugger().GetErrorStream();
This patch modifies the expression parser to allow it to execute expressions even in the absence of a process. This allows expressions to run in situations where the target cannot run -- e.g., to perform calculations based on type information, or to inspect a binary's static data. This modification touches the following files: lldb-private-enumerations.h Introduce a new enum specifying the policy for processing an expression. Some expressions should always be JITted, for example if they are functions that will be used over and over again. Some expressions should always be interpreted, for example if the target is unsafe to run. For most, it is acceptable to JIT them, but interpretation is preferable when possible. Target.[h,cpp] Have EvaluateExpression now accept the new enum. ClangExpressionDeclMap.[cpp,h] Add support for the IR interpreter and also make the ClangExpressionDeclMap more robust in the absence of a process. ClangFunction.[cpp,h] Add support for the new enum. IRInterpreter.[cpp,h] New implementation. ClangUserExpression.[cpp,h] Add support for the new enum, and for running expressions in the absence of a process. ClangExpression.h Remove references to the old DWARF-based method of evaluating expressions, because it has been superseded for now. ClangUtilityFunction.[cpp,h] Add support for the new enum. ClangExpressionParser.[cpp,h] Add support for the new enum, remove references to DWARF, and add support for checking whether the expression could be evaluated statically. IRForTarget.[h,cpp] Add support for the new enum, and add utility functions to support the interpreter. IRToDWARF.cpp Removed CommandObjectExpression.cpp Remove references to the obsolete -i option. Process.cpp Modify calls to ClangUserExpression::Evaluate to pass the correct enum (for dlopen/dlclose) SBValue.cpp Add support for the new enum. SBFrame.cpp Add support for he new enum. BreakpointOptions.cpp Add support for the new enum. llvm-svn: 139772
2011-09-15 10:13:07 +08:00
IRForTarget ir_for_target(decl_map,
m_expr.NeedsVariableResolution(),
*m_execution_unit,
error_stream,
function_name.AsCString());
This is a major refactoring of the expression parser. The goal is to separate the parser's data from the data belonging to the parser's clients. This allows clients to use the parser to obtain (for example) a JIT compiled function or some DWARF code, and then discard the parser state. Previously, parser state was held in ClangExpression and used liberally by ClangFunction, which inherited from ClangExpression. The main effects of this refactoring are: - reducing ClangExpression to an abstract class that declares methods that any client must expose to the expression parser, - moving the code specific to implementing the "expr" command from ClangExpression and CommandObjectExpression into ClangUserExpression, a new class, - moving the common parser interaction code from ClangExpression into ClangExpressionParser, a new class, and - making ClangFunction rely only on ClangExpressionParser and not depend on the internal implementation of ClangExpression. Side effects include: - the compiler interaction code has been factored out of ClangFunction and is now in an AST pass (ASTStructExtractor), - the header file for ClangFunction is now fully documented, - several bugs that only popped up when Clang was deallocated (which never happened, since the lifetime of the compiler was essentially infinite) are now fixed, and - the developer-only "call" command has been disabled. I have tested the expr command and the Objective-C step-into code, which use ClangUserExpression and ClangFunction, respectively, and verified that they work. Please let me know if you encounter bugs or poor documentation. llvm-svn: 112249
2010-08-27 09:01:44 +08:00
bool ir_can_run = ir_for_target.runOnModule(*m_execution_unit->GetModule());
This commit changes the way LLDB executes user expressions. Previously, ClangUserExpression assumed that if there was a constant result for an expression then it could be determined during parsing. In particular, the IRInterpreter ran while parser state (in particular, ClangExpressionDeclMap) was present. This approach is flawed, because the IRInterpreter actually is capable of using external variables, and hence the result might be different each run. Until now, we papered over this flaw by re-parsing the expression each time we ran it. I have rewritten the IRInterpreter to be completely independent of the ClangExpressionDeclMap. Instead of special-casing external variable lookup, which ties the IRInterpreter closely to LLDB, we now interpret the exact same IR that the JIT would see. This IR assumes that materialization has occurred; hence the recent implementation of the Materializer, which does not require parser state (in the form of ClangExpressionDeclMap) to be present. Materialization, interpretation, and dematerialization are now all independent of parsing. This means that in theory we can parse expressions once and run them many times. I have three outstanding tasks before shutting this down: - First, I will ensure that all of this works with core files. Core files have a Process but do not allow allocating memory, which currently confuses materialization. - Second, I will make expression breakpoint conditions remember their ClangUserExpression and re-use it. - Third, I will tear out all the redundant code (for example, materialization logic in ClangExpressionDeclMap) that is no longer used. While implementing this fix, I also found a bug in IRForTarget's handling of floating-point constants. This should be fixed. llvm-svn: 179801
2013-04-19 06:06:33 +08:00
Error interpret_error;
This commit changes the way LLDB executes user expressions. Previously, ClangUserExpression assumed that if there was a constant result for an expression then it could be determined during parsing. In particular, the IRInterpreter ran while parser state (in particular, ClangExpressionDeclMap) was present. This approach is flawed, because the IRInterpreter actually is capable of using external variables, and hence the result might be different each run. Until now, we papered over this flaw by re-parsing the expression each time we ran it. I have rewritten the IRInterpreter to be completely independent of the ClangExpressionDeclMap. Instead of special-casing external variable lookup, which ties the IRInterpreter closely to LLDB, we now interpret the exact same IR that the JIT would see. This IR assumes that materialization has occurred; hence the recent implementation of the Materializer, which does not require parser state (in the form of ClangExpressionDeclMap) to be present. Materialization, interpretation, and dematerialization are now all independent of parsing. This means that in theory we can parse expressions once and run them many times. I have three outstanding tasks before shutting this down: - First, I will ensure that all of this works with core files. Core files have a Process but do not allow allocating memory, which currently confuses materialization. - Second, I will make expression breakpoint conditions remember their ClangUserExpression and re-use it. - Third, I will tear out all the redundant code (for example, materialization logic in ClangExpressionDeclMap) that is no longer used. While implementing this fix, I also found a bug in IRForTarget's handling of floating-point constants. This should be fixed. llvm-svn: 179801
2013-04-19 06:06:33 +08:00
can_interpret = IRInterpreter::CanInterpret(*m_execution_unit->GetModule(), *m_execution_unit->GetFunction(), interpret_error);
Process *process = exe_ctx.GetProcessPtr();
if (!ir_can_run)
{
This commit changes the way LLDB executes user expressions. Previously, ClangUserExpression assumed that if there was a constant result for an expression then it could be determined during parsing. In particular, the IRInterpreter ran while parser state (in particular, ClangExpressionDeclMap) was present. This approach is flawed, because the IRInterpreter actually is capable of using external variables, and hence the result might be different each run. Until now, we papered over this flaw by re-parsing the expression each time we ran it. I have rewritten the IRInterpreter to be completely independent of the ClangExpressionDeclMap. Instead of special-casing external variable lookup, which ties the IRInterpreter closely to LLDB, we now interpret the exact same IR that the JIT would see. This IR assumes that materialization has occurred; hence the recent implementation of the Materializer, which does not require parser state (in the form of ClangExpressionDeclMap) to be present. Materialization, interpretation, and dematerialization are now all independent of parsing. This means that in theory we can parse expressions once and run them many times. I have three outstanding tasks before shutting this down: - First, I will ensure that all of this works with core files. Core files have a Process but do not allow allocating memory, which currently confuses materialization. - Second, I will make expression breakpoint conditions remember their ClangUserExpression and re-use it. - Third, I will tear out all the redundant code (for example, materialization logic in ClangExpressionDeclMap) that is no longer used. While implementing this fix, I also found a bug in IRForTarget's handling of floating-point constants. This should be fixed. llvm-svn: 179801
2013-04-19 06:06:33 +08:00
err.SetErrorString("The expression could not be prepared to run in the target");
return err;
}
This commit changes the way LLDB executes user expressions. Previously, ClangUserExpression assumed that if there was a constant result for an expression then it could be determined during parsing. In particular, the IRInterpreter ran while parser state (in particular, ClangExpressionDeclMap) was present. This approach is flawed, because the IRInterpreter actually is capable of using external variables, and hence the result might be different each run. Until now, we papered over this flaw by re-parsing the expression each time we ran it. I have rewritten the IRInterpreter to be completely independent of the ClangExpressionDeclMap. Instead of special-casing external variable lookup, which ties the IRInterpreter closely to LLDB, we now interpret the exact same IR that the JIT would see. This IR assumes that materialization has occurred; hence the recent implementation of the Materializer, which does not require parser state (in the form of ClangExpressionDeclMap) to be present. Materialization, interpretation, and dematerialization are now all independent of parsing. This means that in theory we can parse expressions once and run them many times. I have three outstanding tasks before shutting this down: - First, I will ensure that all of this works with core files. Core files have a Process but do not allow allocating memory, which currently confuses materialization. - Second, I will make expression breakpoint conditions remember their ClangUserExpression and re-use it. - Third, I will tear out all the redundant code (for example, materialization logic in ClangExpressionDeclMap) that is no longer used. While implementing this fix, I also found a bug in IRForTarget's handling of floating-point constants. This should be fixed. llvm-svn: 179801
2013-04-19 06:06:33 +08:00
if (!can_interpret && execution_policy == eExecutionPolicyNever)
This patch modifies the expression parser to allow it to execute expressions even in the absence of a process. This allows expressions to run in situations where the target cannot run -- e.g., to perform calculations based on type information, or to inspect a binary's static data. This modification touches the following files: lldb-private-enumerations.h Introduce a new enum specifying the policy for processing an expression. Some expressions should always be JITted, for example if they are functions that will be used over and over again. Some expressions should always be interpreted, for example if the target is unsafe to run. For most, it is acceptable to JIT them, but interpretation is preferable when possible. Target.[h,cpp] Have EvaluateExpression now accept the new enum. ClangExpressionDeclMap.[cpp,h] Add support for the IR interpreter and also make the ClangExpressionDeclMap more robust in the absence of a process. ClangFunction.[cpp,h] Add support for the new enum. IRInterpreter.[cpp,h] New implementation. ClangUserExpression.[cpp,h] Add support for the new enum, and for running expressions in the absence of a process. ClangExpression.h Remove references to the old DWARF-based method of evaluating expressions, because it has been superseded for now. ClangUtilityFunction.[cpp,h] Add support for the new enum. ClangExpressionParser.[cpp,h] Add support for the new enum, remove references to DWARF, and add support for checking whether the expression could be evaluated statically. IRForTarget.[h,cpp] Add support for the new enum, and add utility functions to support the interpreter. IRToDWARF.cpp Removed CommandObjectExpression.cpp Remove references to the obsolete -i option. Process.cpp Modify calls to ClangUserExpression::Evaluate to pass the correct enum (for dlopen/dlclose) SBValue.cpp Add support for the new enum. SBFrame.cpp Add support for he new enum. BreakpointOptions.cpp Add support for the new enum. llvm-svn: 139772
2011-09-15 10:13:07 +08:00
{
This commit changes the way LLDB executes user expressions. Previously, ClangUserExpression assumed that if there was a constant result for an expression then it could be determined during parsing. In particular, the IRInterpreter ran while parser state (in particular, ClangExpressionDeclMap) was present. This approach is flawed, because the IRInterpreter actually is capable of using external variables, and hence the result might be different each run. Until now, we papered over this flaw by re-parsing the expression each time we ran it. I have rewritten the IRInterpreter to be completely independent of the ClangExpressionDeclMap. Instead of special-casing external variable lookup, which ties the IRInterpreter closely to LLDB, we now interpret the exact same IR that the JIT would see. This IR assumes that materialization has occurred; hence the recent implementation of the Materializer, which does not require parser state (in the form of ClangExpressionDeclMap) to be present. Materialization, interpretation, and dematerialization are now all independent of parsing. This means that in theory we can parse expressions once and run them many times. I have three outstanding tasks before shutting this down: - First, I will ensure that all of this works with core files. Core files have a Process but do not allow allocating memory, which currently confuses materialization. - Second, I will make expression breakpoint conditions remember their ClangUserExpression and re-use it. - Third, I will tear out all the redundant code (for example, materialization logic in ClangExpressionDeclMap) that is no longer used. While implementing this fix, I also found a bug in IRForTarget's handling of floating-point constants. This should be fixed. llvm-svn: 179801
2013-04-19 06:06:33 +08:00
err.SetErrorStringWithFormat("Can't run the expression locally: %s", interpret_error.AsCString());
This patch modifies the expression parser to allow it to execute expressions even in the absence of a process. This allows expressions to run in situations where the target cannot run -- e.g., to perform calculations based on type information, or to inspect a binary's static data. This modification touches the following files: lldb-private-enumerations.h Introduce a new enum specifying the policy for processing an expression. Some expressions should always be JITted, for example if they are functions that will be used over and over again. Some expressions should always be interpreted, for example if the target is unsafe to run. For most, it is acceptable to JIT them, but interpretation is preferable when possible. Target.[h,cpp] Have EvaluateExpression now accept the new enum. ClangExpressionDeclMap.[cpp,h] Add support for the IR interpreter and also make the ClangExpressionDeclMap more robust in the absence of a process. ClangFunction.[cpp,h] Add support for the new enum. IRInterpreter.[cpp,h] New implementation. ClangUserExpression.[cpp,h] Add support for the new enum, and for running expressions in the absence of a process. ClangExpression.h Remove references to the old DWARF-based method of evaluating expressions, because it has been superseded for now. ClangUtilityFunction.[cpp,h] Add support for the new enum. ClangExpressionParser.[cpp,h] Add support for the new enum, remove references to DWARF, and add support for checking whether the expression could be evaluated statically. IRForTarget.[h,cpp] Add support for the new enum, and add utility functions to support the interpreter. IRToDWARF.cpp Removed CommandObjectExpression.cpp Remove references to the obsolete -i option. Process.cpp Modify calls to ClangUserExpression::Evaluate to pass the correct enum (for dlopen/dlclose) SBValue.cpp Add support for the new enum. SBFrame.cpp Add support for he new enum. BreakpointOptions.cpp Add support for the new enum. llvm-svn: 139772
2011-09-15 10:13:07 +08:00
return err;
}
This commit changes the way LLDB executes user expressions. Previously, ClangUserExpression assumed that if there was a constant result for an expression then it could be determined during parsing. In particular, the IRInterpreter ran while parser state (in particular, ClangExpressionDeclMap) was present. This approach is flawed, because the IRInterpreter actually is capable of using external variables, and hence the result might be different each run. Until now, we papered over this flaw by re-parsing the expression each time we ran it. I have rewritten the IRInterpreter to be completely independent of the ClangExpressionDeclMap. Instead of special-casing external variable lookup, which ties the IRInterpreter closely to LLDB, we now interpret the exact same IR that the JIT would see. This IR assumes that materialization has occurred; hence the recent implementation of the Materializer, which does not require parser state (in the form of ClangExpressionDeclMap) to be present. Materialization, interpretation, and dematerialization are now all independent of parsing. This means that in theory we can parse expressions once and run them many times. I have three outstanding tasks before shutting this down: - First, I will ensure that all of this works with core files. Core files have a Process but do not allow allocating memory, which currently confuses materialization. - Second, I will make expression breakpoint conditions remember their ClangUserExpression and re-use it. - Third, I will tear out all the redundant code (for example, materialization logic in ClangExpressionDeclMap) that is no longer used. While implementing this fix, I also found a bug in IRForTarget's handling of floating-point constants. This should be fixed. llvm-svn: 179801
2013-04-19 06:06:33 +08:00
if (!process && execution_policy == eExecutionPolicyAlways)
{
This commit changes the way LLDB executes user expressions. Previously, ClangUserExpression assumed that if there was a constant result for an expression then it could be determined during parsing. In particular, the IRInterpreter ran while parser state (in particular, ClangExpressionDeclMap) was present. This approach is flawed, because the IRInterpreter actually is capable of using external variables, and hence the result might be different each run. Until now, we papered over this flaw by re-parsing the expression each time we ran it. I have rewritten the IRInterpreter to be completely independent of the ClangExpressionDeclMap. Instead of special-casing external variable lookup, which ties the IRInterpreter closely to LLDB, we now interpret the exact same IR that the JIT would see. This IR assumes that materialization has occurred; hence the recent implementation of the Materializer, which does not require parser state (in the form of ClangExpressionDeclMap) to be present. Materialization, interpretation, and dematerialization are now all independent of parsing. This means that in theory we can parse expressions once and run them many times. I have three outstanding tasks before shutting this down: - First, I will ensure that all of this works with core files. Core files have a Process but do not allow allocating memory, which currently confuses materialization. - Second, I will make expression breakpoint conditions remember their ClangUserExpression and re-use it. - Third, I will tear out all the redundant code (for example, materialization logic in ClangExpressionDeclMap) that is no longer used. While implementing this fix, I also found a bug in IRForTarget's handling of floating-point constants. This should be fixed. llvm-svn: 179801
2013-04-19 06:06:33 +08:00
err.SetErrorString("Expression needed to run in the target, but the target can't be run");
return err;
}
This patch modifies the expression parser to allow it to execute expressions even in the absence of a process. This allows expressions to run in situations where the target cannot run -- e.g., to perform calculations based on type information, or to inspect a binary's static data. This modification touches the following files: lldb-private-enumerations.h Introduce a new enum specifying the policy for processing an expression. Some expressions should always be JITted, for example if they are functions that will be used over and over again. Some expressions should always be interpreted, for example if the target is unsafe to run. For most, it is acceptable to JIT them, but interpretation is preferable when possible. Target.[h,cpp] Have EvaluateExpression now accept the new enum. ClangExpressionDeclMap.[cpp,h] Add support for the IR interpreter and also make the ClangExpressionDeclMap more robust in the absence of a process. ClangFunction.[cpp,h] Add support for the new enum. IRInterpreter.[cpp,h] New implementation. ClangUserExpression.[cpp,h] Add support for the new enum, and for running expressions in the absence of a process. ClangExpression.h Remove references to the old DWARF-based method of evaluating expressions, because it has been superseded for now. ClangUtilityFunction.[cpp,h] Add support for the new enum. ClangExpressionParser.[cpp,h] Add support for the new enum, remove references to DWARF, and add support for checking whether the expression could be evaluated statically. IRForTarget.[h,cpp] Add support for the new enum, and add utility functions to support the interpreter. IRToDWARF.cpp Removed CommandObjectExpression.cpp Remove references to the obsolete -i option. Process.cpp Modify calls to ClangUserExpression::Evaluate to pass the correct enum (for dlopen/dlclose) SBValue.cpp Add support for the new enum. SBFrame.cpp Add support for he new enum. BreakpointOptions.cpp Add support for the new enum. llvm-svn: 139772
2011-09-15 10:13:07 +08:00
This commit changes the way LLDB executes user expressions. Previously, ClangUserExpression assumed that if there was a constant result for an expression then it could be determined during parsing. In particular, the IRInterpreter ran while parser state (in particular, ClangExpressionDeclMap) was present. This approach is flawed, because the IRInterpreter actually is capable of using external variables, and hence the result might be different each run. Until now, we papered over this flaw by re-parsing the expression each time we ran it. I have rewritten the IRInterpreter to be completely independent of the ClangExpressionDeclMap. Instead of special-casing external variable lookup, which ties the IRInterpreter closely to LLDB, we now interpret the exact same IR that the JIT would see. This IR assumes that materialization has occurred; hence the recent implementation of the Materializer, which does not require parser state (in the form of ClangExpressionDeclMap) to be present. Materialization, interpretation, and dematerialization are now all independent of parsing. This means that in theory we can parse expressions once and run them many times. I have three outstanding tasks before shutting this down: - First, I will ensure that all of this works with core files. Core files have a Process but do not allow allocating memory, which currently confuses materialization. - Second, I will make expression breakpoint conditions remember their ClangUserExpression and re-use it. - Third, I will tear out all the redundant code (for example, materialization logic in ClangExpressionDeclMap) that is no longer used. While implementing this fix, I also found a bug in IRForTarget's handling of floating-point constants. This should be fixed. llvm-svn: 179801
2013-04-19 06:06:33 +08:00
if (execution_policy == eExecutionPolicyAlways || !can_interpret)
{
if (m_expr.NeedsValidation() && process)
{
if (!process->GetDynamicCheckers())
{
DynamicCheckerFunctions *dynamic_checkers = new DynamicCheckerFunctions();
StreamString install_errors;
if (!dynamic_checkers->Install(install_errors, exe_ctx))
{
if (install_errors.GetString().empty())
err.SetErrorString ("couldn't install checkers, unknown error");
else
err.SetErrorString (install_errors.GetString().c_str());
return err;
}
process->SetDynamicCheckers(dynamic_checkers);
if (log)
log->Printf("== [ClangUserExpression::Evaluate] Finished installing dynamic checkers ==");
}
This commit changes the way LLDB executes user expressions. Previously, ClangUserExpression assumed that if there was a constant result for an expression then it could be determined during parsing. In particular, the IRInterpreter ran while parser state (in particular, ClangExpressionDeclMap) was present. This approach is flawed, because the IRInterpreter actually is capable of using external variables, and hence the result might be different each run. Until now, we papered over this flaw by re-parsing the expression each time we ran it. I have rewritten the IRInterpreter to be completely independent of the ClangExpressionDeclMap. Instead of special-casing external variable lookup, which ties the IRInterpreter closely to LLDB, we now interpret the exact same IR that the JIT would see. This IR assumes that materialization has occurred; hence the recent implementation of the Materializer, which does not require parser state (in the form of ClangExpressionDeclMap) to be present. Materialization, interpretation, and dematerialization are now all independent of parsing. This means that in theory we can parse expressions once and run them many times. I have three outstanding tasks before shutting this down: - First, I will ensure that all of this works with core files. Core files have a Process but do not allow allocating memory, which currently confuses materialization. - Second, I will make expression breakpoint conditions remember their ClangUserExpression and re-use it. - Third, I will tear out all the redundant code (for example, materialization logic in ClangExpressionDeclMap) that is no longer used. While implementing this fix, I also found a bug in IRForTarget's handling of floating-point constants. This should be fixed. llvm-svn: 179801
2013-04-19 06:06:33 +08:00
IRDynamicChecks ir_dynamic_checks(*process->GetDynamicCheckers(), function_name.AsCString());
if (!ir_dynamic_checks.runOnModule(*m_execution_unit->GetModule()))
{
err.SetErrorToGenericError();
err.SetErrorString("Couldn't add dynamic checks to the expression");
return err;
}
}
This commit changes the way LLDB executes user expressions. Previously, ClangUserExpression assumed that if there was a constant result for an expression then it could be determined during parsing. In particular, the IRInterpreter ran while parser state (in particular, ClangExpressionDeclMap) was present. This approach is flawed, because the IRInterpreter actually is capable of using external variables, and hence the result might be different each run. Until now, we papered over this flaw by re-parsing the expression each time we ran it. I have rewritten the IRInterpreter to be completely independent of the ClangExpressionDeclMap. Instead of special-casing external variable lookup, which ties the IRInterpreter closely to LLDB, we now interpret the exact same IR that the JIT would see. This IR assumes that materialization has occurred; hence the recent implementation of the Materializer, which does not require parser state (in the form of ClangExpressionDeclMap) to be present. Materialization, interpretation, and dematerialization are now all independent of parsing. This means that in theory we can parse expressions once and run them many times. I have three outstanding tasks before shutting this down: - First, I will ensure that all of this works with core files. Core files have a Process but do not allow allocating memory, which currently confuses materialization. - Second, I will make expression breakpoint conditions remember their ClangUserExpression and re-use it. - Third, I will tear out all the redundant code (for example, materialization logic in ClangExpressionDeclMap) that is no longer used. While implementing this fix, I also found a bug in IRForTarget's handling of floating-point constants. This should be fixed. llvm-svn: 179801
2013-04-19 06:06:33 +08:00
m_execution_unit->GetRunnableInfo(err, func_addr, func_end);
}
This is a major refactoring of the expression parser. The goal is to separate the parser's data from the data belonging to the parser's clients. This allows clients to use the parser to obtain (for example) a JIT compiled function or some DWARF code, and then discard the parser state. Previously, parser state was held in ClangExpression and used liberally by ClangFunction, which inherited from ClangExpression. The main effects of this refactoring are: - reducing ClangExpression to an abstract class that declares methods that any client must expose to the expression parser, - moving the code specific to implementing the "expr" command from ClangExpression and CommandObjectExpression into ClangUserExpression, a new class, - moving the common parser interaction code from ClangExpression into ClangExpressionParser, a new class, and - making ClangFunction rely only on ClangExpressionParser and not depend on the internal implementation of ClangExpression. Side effects include: - the compiler interaction code has been factored out of ClangFunction and is now in an AST pass (ASTStructExtractor), - the header file for ClangFunction is now fully documented, - several bugs that only popped up when Clang was deallocated (which never happened, since the lifetime of the compiler was essentially infinite) are now fixed, and - the developer-only "call" command has been disabled. I have tested the expr command and the Objective-C step-into code, which use ClangUserExpression and ClangFunction, respectively, and verified that they work. Please let me know if you encounter bugs or poor documentation. llvm-svn: 112249
2010-08-27 09:01:44 +08:00
}
This commit changes the way LLDB executes user expressions. Previously, ClangUserExpression assumed that if there was a constant result for an expression then it could be determined during parsing. In particular, the IRInterpreter ran while parser state (in particular, ClangExpressionDeclMap) was present. This approach is flawed, because the IRInterpreter actually is capable of using external variables, and hence the result might be different each run. Until now, we papered over this flaw by re-parsing the expression each time we ran it. I have rewritten the IRInterpreter to be completely independent of the ClangExpressionDeclMap. Instead of special-casing external variable lookup, which ties the IRInterpreter closely to LLDB, we now interpret the exact same IR that the JIT would see. This IR assumes that materialization has occurred; hence the recent implementation of the Materializer, which does not require parser state (in the form of ClangExpressionDeclMap) to be present. Materialization, interpretation, and dematerialization are now all independent of parsing. This means that in theory we can parse expressions once and run them many times. I have three outstanding tasks before shutting this down: - First, I will ensure that all of this works with core files. Core files have a Process but do not allow allocating memory, which currently confuses materialization. - Second, I will make expression breakpoint conditions remember their ClangUserExpression and re-use it. - Third, I will tear out all the redundant code (for example, materialization logic in ClangExpressionDeclMap) that is no longer used. While implementing this fix, I also found a bug in IRForTarget's handling of floating-point constants. This should be fixed. llvm-svn: 179801
2013-04-19 06:06:33 +08:00
else
{
m_execution_unit->GetRunnableInfo(err, func_addr, func_end);
}
execution_unit_ap.reset (m_execution_unit.release());
This is a major refactoring of the expression parser. The goal is to separate the parser's data from the data belonging to the parser's clients. This allows clients to use the parser to obtain (for example) a JIT compiled function or some DWARF code, and then discard the parser state. Previously, parser state was held in ClangExpression and used liberally by ClangFunction, which inherited from ClangExpression. The main effects of this refactoring are: - reducing ClangExpression to an abstract class that declares methods that any client must expose to the expression parser, - moving the code specific to implementing the "expr" command from ClangExpression and CommandObjectExpression into ClangUserExpression, a new class, - moving the common parser interaction code from ClangExpression into ClangExpressionParser, a new class, and - making ClangFunction rely only on ClangExpressionParser and not depend on the internal implementation of ClangExpression. Side effects include: - the compiler interaction code has been factored out of ClangFunction and is now in an AST pass (ASTStructExtractor), - the header file for ClangFunction is now fully documented, - several bugs that only popped up when Clang was deallocated (which never happened, since the lifetime of the compiler was essentially infinite) are now fixed, and - the developer-only "call" command has been disabled. I have tested the expr command and the Objective-C step-into code, which use ClangUserExpression and ClangFunction, respectively, and verified that they work. Please let me know if you encounter bugs or poor documentation. llvm-svn: 112249
2010-08-27 09:01:44 +08:00
return err;
}