maxjhandsome
/
llvm-project
forked from OSchip/llvm-project
1
0
Fork 0
Code Issues Pull Requests Packages Releases Wiki Activity
llvm-project/lldb/source/Expression/ClangUserExpression.cpp

680 lines
25 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
//===-- ClangUserExpression.cpp -------------------------------------*- C++ -*-===//
//
// The LLVM Compiler Infrastructure
//
// This file is distributed under the University of Illinois Open Source
// License. See LICENSE.TXT for details.
//
//===----------------------------------------------------------------------===//
// C Includes
#include <stdio.h>
#if HAVE_SYS_TYPES_H
# include <sys/types.h>
#endif
// C++ Includes
#include <cstdlib>
#include <string>
#include <map>
#include "lldb/Core/ConstString.h"
#include "lldb/Core/Log.h"
Thread safety changes in debugserver and also in the process GDB remote plugin. I added support for asking if the GDB remote server supports thread suffixes for packets that should be thread specific (register read/write packets) because the way the GDB remote protocol does it right now is to have a notion of a current thread for register and memory reads/writes (set via the "$Hg%x" packet) and a current thread for running ("$Hc%x"). Now we ask the remote GDB server if it supports adding the thread ID to the register packets and we enable that feature in LLDB if supported. This stops us from having to send a bunch of packets that update the current thread ID to some value which is prone to error, or extra packets. llvm-svn: 123762
2011-01-19 03:36:39 +08:00
#include "lldb/Core/StreamFile.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/StreamString.h"
Added the notion that a value object can be constant by adding: bool ValueObject::GetIsConstant() const; void ValueObject::SetIsConstant(); This will stop anything from being re-evaluated within the value object so that constant result value objects can maintain their frozen values without anything being updated or changed within the value object. Made it so the ValueObjectConstResult can be constructed with an lldb_private::Error object to allow for expression results to have errors. Since ValueObject objects contain error objects, I changed the expression evaluation in ClangUserExpression from static Error ClangUserExpression::Evaluate (ExecutionContext &exe_ctx, const char *expr_cstr, lldb::ValueObjectSP &result_valobj_sp); to: static lldb::ValueObjectSP Evaluate (ExecutionContext &exe_ctx, const char *expr_cstr); Even though expression parsing is borked right now (pending fixes coming from Sean Callanan), I filled in the implementation for: SBValue SBFrame::EvaluateExpression (const char *expr); Modified all expression code to deal with the above changes. llvm-svn: 115589
2010-10-05 11:13:51 +08:00
#include "lldb/Core/ValueObjectConstResult.h"
Implemented a feature where the expression parser can avoid running the code in the target if the expression's result is known and the expression has no side effects. Right now this feature is quite conservative in its guess about side effects, and it only computes integer results, but the machinery to make it more sophisticated is there. llvm-svn: 121952
2010-12-16 11:17:46 +08:00
#include "lldb/Expression/ASTResultSynthesizer.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/ClangExpressionDeclMap.h"
#include "lldb/Expression/ClangExpressionParser.h"
#include "lldb/Expression/ClangFunction.h"
#include "lldb/Expression/ClangUserExpression.h"
#include "lldb/Host/Host.h"
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
#include "lldb/Symbol/VariableList.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"
Added support for loading and unloading shared libraries. This was done by adding support into lldb_private::Process: virtual uint32_t lldb_private::Process::LoadImage (const FileSpec &image_spec, Error &error); virtual Error lldb_private::Process::UnloadImage (uint32_t image_token); There is a default implementation that should work for both linux and MacOSX. This ability has also been exported through the SBProcess API: uint32_t lldb::SBProcess::LoadImage (lldb::SBFileSpec &image_spec, lldb::SBError &error); lldb::SBError lldb::SBProcess::UnloadImage (uint32_t image_token); Modified the DynamicLoader plug-in interface to require it to be able to tell us if it is currently possible to load/unload a shared library: virtual lldb_private::Error DynamicLoader::CanLoadImage () = 0; This way the dynamic loader plug-ins are allows to veto whether we can currently load a shared library since the dynamic loader might know if it is currenlty loading/unloading shared libraries. It might also know about the current host system and know where to check to make sure runtime or malloc locks are currently being held. Modified the expression parser to have ClangUserExpression::Evaluate() be the one that causes the dynamic checkers to be loaded instead of other code that shouldn't have to worry about it. llvm-svn: 118227
2010-11-04 09:54:29 +08:00
#include "lldb/Target/Process.h"
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
#include "lldb/Target/StackFrame.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/Target.h"
Moved the code in ClangUserExpression that set up & ran the thread plan with timeouts, and restarting with all threads into a utility function in Process. This required a bunch of renaming. Added a ThreadPlanCallUserExpression that differs from ThreadPlanCallFunction in that it holds onto a shared pointer to its ClangUserExpression so that can't go away before the thread plan is done using it. Fixed the stop message when you hit a breakpoint while running a user expression so it is more obvious what has happened. llvm-svn: 120386
2010-11-30 10:22:11 +08:00
#include "lldb/Target/ThreadPlan.h"
#include "lldb/Target/ThreadPlanCallUserExpression.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 lldb_private;
Added a user-settable variable, 'target.expr-prefix', which holds the name of a file whose contents are prefixed to each expression. For example, if the file ~/lldb.prefix.header contains: typedef unsigned short my_type; then you can do this: (lldb) settings set target.expr-prefix '~/lldb.prefix.header' (lldb) expr sizeof(my_type) (unsigned long) $0 = 2 When the variable is changed, the corresponding file is loaded and its contents are fetched into a string that is stored along with the target. This string is then passed to each expression and inserted into it during parsing, like this: typedef unsigned short my_type; void $__lldb_expr(void *$__lldb_arg) { sizeof(my_type); } llvm-svn: 117627
2010-10-29 08:29:03 +08:00
ClangUserExpression::ClangUserExpression (const char *expr,
const char *expr_prefix) :
Make expressions clean up their JIT'ed code allocation. llvm-svn: 123855
2011-01-20 07:00:49 +08:00
ClangExpression (),
m_expr_text (expr),
m_expr_prefix (expr_prefix ? expr_prefix : ""),
m_transformed_text (),
Order of initialization lists. This patch fixes all of the warnings due to unordered initialization lists. Patch by Marco Minutoli. llvm-svn: 129290
2011-04-12 03:41:40 +08:00
m_desired_type (NULL, NULL),
Make expressions clean up their JIT'ed code allocation. llvm-svn: 123855
2011-01-20 07:00:49 +08:00
m_cplusplus (false),
m_objectivec (false),
m_needs_object_ptr (false),
Made expressions that are just casts of pointer variables be evaluated statically. Also fixed a bug that caused the results of statically-evaluated expressions to be materialized improperly. This bug also removes some duplicate code. llvm-svn: 131042
2011-05-07 09:06:41 +08:00
m_const_object (false),
m_const_result ()
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
{
}
Added a ClangUtilityFunction class that allows the debugger to insert self-contained functions for use by expressions (mainly for error-checking). In order to support detecting whether a crash occurred in one of these helpers -- currently our preferred way of reporting that an error-check failed -- added a bit of support for getting the extent of a JITted function in addition to just its base. llvm-svn: 112324
2010-08-28 07:31:21 +08:00
ClangUserExpression::~ClangUserExpression ()
{
}
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
clang::ASTConsumer *
ClangUserExpression::ASTTransformer (clang::ASTConsumer *passthrough)
{
Added support for indicating to the expression parser that the result of an expression should be coerced to a specific type. Also made breakpoint conditions pass in the bool type for this type. The expression parser ignores this indication for now. llvm-svn: 119779
2010-11-19 10:52:21 +08:00
return new ASTResultSynthesizer(passthrough,
m_desired_type);
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
}
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
void
ClangUserExpression::ScanContext(ExecutionContext &exe_ctx)
{
if (!exe_ctx.frame)
return;
VariableList *vars = exe_ctx.frame->GetVariableList(false);
if (!vars)
return;
Fixed ClangUserExpression's wrapping of expressions in C++ methods. There were two fixes involved: - For an object whose contents are not known, the expression should be treated as a non-member, and "this" should have no meaning. - For a const object, the method should be declared const as well. llvm-svn: 120606
2010-12-02 05:35:54 +08:00
lldb::VariableSP this_var(vars->FindVariable(ConstString("this")));
lldb::VariableSP self_var(vars->FindVariable(ConstString("self")));
if (this_var.get())
{
Type *this_type = this_var->GetType();
lldb::clang_type_t pointer_target_type;
Clean up a bit of the type getting code where lldb_private:Type now has clang_type_t GetClangFullType(); // Get a completely defined clang type clang_type_t GetClangLayoutType(); // Get a clang type that can be used for type layout clang_type_t GetClangForwardType(); // A type that can be completed if needed, but is more efficient. llvm-svn: 125691
2011-02-17 07:00:21 +08:00
if (ClangASTContext::IsPointerType(this_type->GetClangForwardType(),
Fixed ClangUserExpression's wrapping of expressions in C++ methods. There were two fixes involved: - For an object whose contents are not known, the expression should be treated as a non-member, and "this" should have no meaning. - For a const object, the method should be declared const as well. llvm-svn: 120606
2010-12-02 05:35:54 +08:00
&pointer_target_type))
{
TypeFromUser target_ast_type(pointer_target_type, this_type->GetClangAST());
Clean up a bit of the type getting code where lldb_private:Type now has clang_type_t GetClangFullType(); // Get a completely defined clang type clang_type_t GetClangLayoutType(); // Get a clang type that can be used for type layout clang_type_t GetClangForwardType(); // A type that can be completed if needed, but is more efficient. llvm-svn: 125691
2011-02-17 07:00:21 +08:00
if (ClangASTContext::IsCXXClassType(target_ast_type.GetOpaqueQualType()))
Fixed a bug in the expression code which caused it to interpret a "this" variable that was merely a pointer -- that is, not a class pointer -- as meaning that the current context was inside a C++ method. This bug would prevent expressions from evaluating correctly in regular C code if there was a pointer variable named "this" in scope. llvm-svn: 124117
2011-01-24 16:11:45 +08:00
{
Fixed ClangUserExpression's wrapping of expressions in C++ methods. There were two fixes involved: - For an object whose contents are not known, the expression should be treated as a non-member, and "this" should have no meaning. - For a const object, the method should be declared const as well. llvm-svn: 120606
2010-12-02 05:35:54 +08:00
m_cplusplus = true;
Fixed a bug in the expression code which caused it to interpret a "this" variable that was merely a pointer -- that is, not a class pointer -- as meaning that the current context was inside a C++ method. This bug would prevent expressions from evaluating correctly in regular C code if there was a pointer variable named "this" in scope. llvm-svn: 124117
2011-01-24 16:11:45 +08:00
if (target_ast_type.IsConst())
m_const_object = true;
}
Fixed ClangUserExpression's wrapping of expressions in C++ methods. There were two fixes involved: - For an object whose contents are not known, the expression should be treated as a non-member, and "this" should have no meaning. - For a const object, the method should be declared const as well. llvm-svn: 120606
2010-12-02 05:35:54 +08:00
}
}
else if (self_var.get())
{
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_objectivec = true;
Fixed ClangUserExpression's wrapping of expressions in C++ methods. There were two fixes involved: - For an object whose contents are not known, the expression should be treated as a non-member, and "this" should have no meaning. - For a const object, the method should be declared const as well. llvm-svn: 120606
2010-12-02 05:35:54 +08:00
}
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
}
Added a temporary hack to allow casting of Objective-C method results to int. This will only last until we get accurate type information for Objective-C methods or some way of making their types inferred by the parser. llvm-svn: 117178
2010-10-23 07:25:16 +08:00
// This is a really nasty hack, meant to fix Objective-C expressions of the form
// (int)[myArray count]. Right now, because the type information for count is
// not available, [myArray count] returns id, which can't be directly cast to
// int without causing a clang error.
static void
ApplyObjcCastHack(std::string &expr)
{
#define OBJC_CAST_HACK_FROM "(int)["
#define OBJC_CAST_HACK_TO "(int)(long long)["
size_t from_offset;
while ((from_offset = expr.find(OBJC_CAST_HACK_FROM)) != expr.npos)
expr.replace(from_offset, sizeof(OBJC_CAST_HACK_FROM) - 1, OBJC_CAST_HACK_TO);
#undef OBJC_CAST_HACK_TO
#undef OBJC_CAST_HACK_FROM
}
Added a hack so that "unichar" is resolved to "unsigned short." As discussed in the comments, this is pending a better solution to the problem of types not in the debug information but readily available through headers. llvm-svn: 117247
2010-10-25 04:45:49 +08:00
// Another hack, meant to allow use of unichar despite it not being available in
// the type information. Although we could special-case it in type lookup,
// hopefully we'll figure out a way to #include the same environment as is
// present in the original source file rather than try to hack specific type
// definitions in as needed.
static void
ApplyUnicharHack(std::string &expr)
{
#define UNICHAR_HACK_FROM "unichar"
#define UNICHAR_HACK_TO "unsigned short"
size_t from_offset;
while ((from_offset = expr.find(UNICHAR_HACK_FROM)) != expr.npos)
expr.replace(from_offset, sizeof(UNICHAR_HACK_FROM) - 1, UNICHAR_HACK_TO);
#undef UNICHAR_HACK_TO
#undef UNICHAR_HACK_FROM
}
Added a temporary hack to allow casting of Objective-C method results to int. This will only last until we get accurate type information for Objective-C methods or some way of making their types inferred by the parser. llvm-svn: 117178
2010-10-23 07:25:16 +08:00
bool
Added support for indicating to the expression parser that the result of an expression should be coerced to a specific type. Also made breakpoint conditions pass in the bool type for this type. The expression parser ignores this indication for now. llvm-svn: 119779
2010-11-19 10:52:21 +08:00
ClangUserExpression::Parse (Stream &error_stream,
ExecutionContext &exe_ctx,
Implemented a feature where the expression parser can avoid running the code in the target if the expression's result is known and the expression has no side effects. Right now this feature is quite conservative in its guess about side effects, and it only computes integer results, but the machinery to make it more sophisticated is there. llvm-svn: 121952
2010-12-16 11:17:46 +08:00
TypeFromUser desired_type,
Made expressions that are just casts of pointer variables be evaluated statically. Also fixed a bug that caused the results of statically-evaluated expressions to be materialized improperly. This bug also removes some duplicate code. llvm-svn: 131042
2011-05-07 09:06:41 +08:00
bool keep_result_in_memory)
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
{
Modified all logging calls to hand out shared pointers to make sure we don't crash if we disable logging when some code already has a copy of the logger. Prior to this fix, logs were handed out as pointers and if they were held onto while a log got disabled, then it could cause a crash. Now all logs are handed out as shared pointers so this problem shouldn't happen anymore. We are also using our new shared pointers that put the shared pointer count and the object into the same allocation for a tad better performance. llvm-svn: 118319
2010-11-06 09:53:30 +08:00
lldb::LogSP log(lldb_private::GetLogIfAllCategoriesSet (LIBLLDB_LOG_EXPRESSIONS));
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
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
ScanContext(exe_ctx);
StreamString m_transformed_stream;
////////////////////////////////////
// Generate the expression
//
Added a temporary hack to allow casting of Objective-C method results to int. This will only last until we get accurate type information for Objective-C methods or some way of making their types inferred by the parser. llvm-svn: 117178
2010-10-23 07:25:16 +08:00
ApplyObjcCastHack(m_expr_text);
Updated the lldb_private::Flags class to have better method names and made all of the calls inlined in the header file for better performance. Fixed the summary for C string types (array of chars (with any combo if modifiers), and pointers to chars) work in all cases. Fixed an issue where a forward declaration to a clang type could cause itself to resolve itself more than once if, during the resolving of the type itself it caused something to try and resolve itself again. We now remove the clang type from the forward declaration map in the DWARF parser when we start to resolve it and avoid this additional call. This should stop any duplicate members from appearing and throwing all the alignment of structs, unions and classes. llvm-svn: 117437
2010-10-27 11:32:59 +08:00
//ApplyUnicharHack(m_expr_text);
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 (m_cplusplus)
{
Added a user-settable variable, 'target.expr-prefix', which holds the name of a file whose contents are prefixed to each expression. For example, if the file ~/lldb.prefix.header contains: typedef unsigned short my_type; then you can do this: (lldb) settings set target.expr-prefix '~/lldb.prefix.header' (lldb) expr sizeof(my_type) (unsigned long) $0 = 2 When the variable is changed, the corresponding file is loaded and its contents are fetched into a string that is stored along with the target. This string is then passed to each expression and inserted into it during parsing, like this: typedef unsigned short my_type; void $__lldb_expr(void *$__lldb_arg) { sizeof(my_type); } llvm-svn: 117627
2010-10-29 08:29:03 +08:00
m_transformed_stream.Printf("%s \n"
"typedef unsigned short unichar; \n"
Updated the lldb_private::Flags class to have better method names and made all of the calls inlined in the header file for better performance. Fixed the summary for C string types (array of chars (with any combo if modifiers), and pointers to chars) work in all cases. Fixed an issue where a forward declaration to a clang type could cause itself to resolve itself more than once if, during the resolving of the type itself it caused something to try and resolve itself again. We now remove the clang type from the forward declaration map in the DWARF parser when we start to resolve it and avoid this additional call. This should stop any duplicate members from appearing and throwing all the alignment of structs, unions and classes. llvm-svn: 117437
2010-10-27 11:32:59 +08:00
"void \n"
Fixed ClangUserExpression's wrapping of expressions in C++ methods. There were two fixes involved: - For an object whose contents are not known, the expression should be treated as a non-member, and "this" should have no meaning. - For a const object, the method should be declared const as well. llvm-svn: 120606
2010-12-02 05:35:54 +08:00
"$__lldb_class::%s(void *$__lldb_arg) %s\n"
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
"{ \n"
" %s; \n"
"} \n",
Added a user-settable variable, 'target.expr-prefix', which holds the name of a file whose contents are prefixed to each expression. For example, if the file ~/lldb.prefix.header contains: typedef unsigned short my_type; then you can do this: (lldb) settings set target.expr-prefix '~/lldb.prefix.header' (lldb) expr sizeof(my_type) (unsigned long) $0 = 2 When the variable is changed, the corresponding file is loaded and its contents are fetched into a string that is stored along with the target. This string is then passed to each expression and inserted into it during parsing, like this: typedef unsigned short my_type; void $__lldb_expr(void *$__lldb_arg) { sizeof(my_type); } llvm-svn: 117627
2010-10-29 08:29:03 +08:00
m_expr_prefix.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
FunctionName(),
Fixed ClangUserExpression's wrapping of expressions in C++ methods. There were two fixes involved: - For an object whose contents are not known, the expression should be treated as a non-member, and "this" should have no meaning. - For a const object, the method should be declared const as well. llvm-svn: 120606
2010-12-02 05:35:54 +08:00
(m_const_object ? "const" : ""),
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_expr_text.c_str());
m_needs_object_ptr = true;
}
Added support for generating expressions that have access to the members of the Objective-C self object. The approach we take is to generate the method as a @category on top of the self object, and to pass the "self" pointer to it. (_cmd is currently NULL.) Most changes are in ClangExpressionDeclMap, but the change that adds support to the ABIs to pass _cmd touches a fair amount of code. llvm-svn: 121722
2010-12-14 06:46:15 +08:00
else if(m_objectivec)
{
const char *function_name = FunctionName();
m_transformed_stream.Printf("%s \n"
Added access to set the current stack frame within a thread so any command line commands can use the current thread/frame. Fixed an issue with expressions that get sandboxed in an objective C method where unichar wasn't being passed down. Added a "static size_t Scalar::GetMaxByteSize();" function in case we need to know the max supported by size of something within a Scalar object. llvm-svn: 122027
2010-12-17 10:26:24 +08:00
"typedef unsigned short unichar; \n"
Added support for generating expressions that have access to the members of the Objective-C self object. The approach we take is to generate the method as a @category on top of the self object, and to pass the "self" pointer to it. (_cmd is currently NULL.) Most changes are in ClangExpressionDeclMap, but the change that adds support to the ABIs to pass _cmd touches a fair amount of code. llvm-svn: 121722
2010-12-14 06:46:15 +08:00
"@interface $__lldb_objc_class ($__lldb_category) \n"
"-(void)%s:(void *)$__lldb_arg; \n"
"@end \n"
"@implementation $__lldb_objc_class ($__lldb_category) \n"
"-(void)%s:(void *)$__lldb_arg \n"
"{ \n"
" %s; \n"
"} \n"
"@end \n",
m_expr_prefix.c_str(),
function_name,
function_name,
m_expr_text.c_str());
m_needs_object_ptr = true;
}
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
else
{
Added a user-settable variable, 'target.expr-prefix', which holds the name of a file whose contents are prefixed to each expression. For example, if the file ~/lldb.prefix.header contains: typedef unsigned short my_type; then you can do this: (lldb) settings set target.expr-prefix '~/lldb.prefix.header' (lldb) expr sizeof(my_type) (unsigned long) $0 = 2 When the variable is changed, the corresponding file is loaded and its contents are fetched into a string that is stored along with the target. This string is then passed to each expression and inserted into it during parsing, like this: typedef unsigned short my_type; void $__lldb_expr(void *$__lldb_arg) { sizeof(my_type); } llvm-svn: 117627
2010-10-29 08:29:03 +08:00
m_transformed_stream.Printf("%s \n"
"typedef unsigned short unichar;\n"
Updated the lldb_private::Flags class to have better method names and made all of the calls inlined in the header file for better performance. Fixed the summary for C string types (array of chars (with any combo if modifiers), and pointers to chars) work in all cases. Fixed an issue where a forward declaration to a clang type could cause itself to resolve itself more than once if, during the resolving of the type itself it caused something to try and resolve itself again. We now remove the clang type from the forward declaration map in the DWARF parser when we start to resolve it and avoid this additional call. This should stop any duplicate members from appearing and throwing all the alignment of structs, unions and classes. llvm-svn: 117437
2010-10-27 11:32:59 +08:00
"void \n"
Added a temporary hack to allow casting of Objective-C method results to int. This will only last until we get accurate type information for Objective-C methods or some way of making their types inferred by the parser. llvm-svn: 117178
2010-10-23 07:25:16 +08:00
"%s(void *$__lldb_arg) \n"
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
"{ \n"
" %s; \n"
"} \n",
Added a user-settable variable, 'target.expr-prefix', which holds the name of a file whose contents are prefixed to each expression. For example, if the file ~/lldb.prefix.header contains: typedef unsigned short my_type; then you can do this: (lldb) settings set target.expr-prefix '~/lldb.prefix.header' (lldb) expr sizeof(my_type) (unsigned long) $0 = 2 When the variable is changed, the corresponding file is loaded and its contents are fetched into a string that is stored along with the target. This string is then passed to each expression and inserted into it during parsing, like this: typedef unsigned short my_type; void $__lldb_expr(void *$__lldb_arg) { sizeof(my_type); } llvm-svn: 117627
2010-10-29 08:29:03 +08:00
m_expr_prefix.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
FunctionName(),
m_expr_text.c_str());
}
m_transformed_text = m_transformed_stream.GetData();
if (log)
log->Printf("Parsing the following code:\n%s", m_transformed_text.c_str());
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 up the target and compiler
//
Target *target = exe_ctx.target;
if (!target)
{
error_stream.PutCString ("error: invalid target\n");
return false;
}
//////////////////////////
// Parse the expression
//
Added support for indicating to the expression parser that the result of an expression should be coerced to a specific type. Also made breakpoint conditions pass in the bool type for this type. The expression parser ignores this indication for now. llvm-svn: 119779
2010-11-19 10:52:21 +08:00
m_desired_type = desired_type;
Implemented a major overhaul of the way variables are handled by LLDB. Instead of being materialized into the input structure passed to the expression, variables are left in place and pointers to them are materialzied into the structure. Variables not resident in memory (notably, registers) get temporary memory regions allocated for them. Persistent variables are the most complex part of this, because they are made in various ways and there are different expectations about their lifetime. Persistent variables now have flags indicating their status and what the expectations for longevity are. They can be marked as residing in target memory permanently -- this is the default for result variables from expressions entered on the command line and for explicitly declared persistent variables (but more on that below). Other result variables have their memory freed. Some major improvements resulting from this include being able to properly take the address of variables, better and cleaner support for functions that return references, and cleaner C++ support in general. One problem that remains is the problem of explicitly declared persistent variables; I have not yet implemented the code that makes references to them into indirect references, so currently materialization and dematerialization of these variables is broken. llvm-svn: 123371
2011-01-13 16:53:35 +08:00
m_expr_decl_map.reset(new ClangExpressionDeclMap(keep_result_in_memory));
Fixed object lifetimes in ClangExpressionDeclMap so that it is not referring to potentially stale state during IR execution. This was done by introducing modular state (like ClangExpressionVariable) where groups of state variables have well-defined lifetimes: - m_parser_vars are specific to parsing, and only exist between calls to WillParse() and DidParse(). - m_struct_vars survive for the entire execution of the ClangExpressionDeclMap because they provide the template for a materialized set of expression variables. - m_material_vars are specific to a single instance of materialization, and only exist between calls to Materialize() and Dematerialize(). I also removed unnecessary references to long- lived state that really didn't need to be referred to at all, and also introduced several assert()s that helped me diagnose a few bugs (fixed too). llvm-svn: 120778
2010-12-03 09:38:59 +08:00
m_expr_decl_map->WillParse(exe_ctx);
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
Made lldb_private::ArchSpec contain much more than just an architecture. It now, in addition to cpu type/subtype and architecture flavor, contains: - byte order (big endian, little endian) - address size in bytes - llvm::Triple for true target triple support and for more powerful plug-in selection. llvm-svn: 125602
2011-02-16 05:59:32 +08:00
ClangExpressionParser parser(exe_ctx.process, *this);
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
unsigned num_errors = parser.Parse (error_stream);
if (num_errors)
{
error_stream.Printf ("error: %d errors parsing expression\n", num_errors);
Fixed object lifetimes in ClangExpressionDeclMap so that it is not referring to potentially stale state during IR execution. This was done by introducing modular state (like ClangExpressionVariable) where groups of state variables have well-defined lifetimes: - m_parser_vars are specific to parsing, and only exist between calls to WillParse() and DidParse(). - m_struct_vars survive for the entire execution of the ClangExpressionDeclMap because they provide the template for a materialized set of expression variables. - m_material_vars are specific to a single instance of materialization, and only exist between calls to Materialize() and Dematerialize(). I also removed unnecessary references to long- lived state that really didn't need to be referred to at all, and also introduced several assert()s that helped me diagnose a few bugs (fixed too). llvm-svn: 120778
2010-12-03 09:38:59 +08:00
m_expr_decl_map->DidParse();
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 false;
}
///////////////////////////////////////////////
// Convert the output of the parser to DWARF
//
m_dwarf_opcodes.reset(new StreamString);
Endian patch from Kirk Beitz that allows better cross platform building. llvm-svn: 124643
2011-02-01 09:31:41 +08:00
m_dwarf_opcodes->SetByteOrder (lldb::endian::InlHostByteOrder());
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_dwarf_opcodes->GetFlags ().Set (Stream::eBinary);
Modified LLDB expressions to not have to JIT and run code just to see variable values or persistent expression variables. Now if an expression consists of a value that is a child of a variable, or of a persistent variable only, we will create a value object for it and make a ValueObjectConstResult from it to freeze the value (for program variables only, not persistent variables) and avoid running JITed code. For everything else we still parse up and JIT code and run it in the inferior. There was also a lot of clean up in the expression code. I made the ClangExpressionVariables be stored in collections of shared pointers instead of in collections of objects. This will help stop a lot of copy constructors on these large objects and also cleans up the code considerably. The persistent clang expression variables were moved over to the Target to ensure they persist across process executions. Added the ability for lldb_private::Target objects to evaluate expressions. We want to evaluate expressions at the target level in case we aren't running yet, or we have just completed running. We still want to be able to access the persistent expression variables between runs, and also evaluate constant expressions. Added extra logging to the dynamic loader plug-in for MacOSX. ModuleList objects can now dump their contents with the UUID, arch and full paths being logged with appropriate prefix values. Thread hardened the Communication class a bit by making the connection auto_ptr member into a shared pointer member and then making a local copy of the shared pointer in each method that uses it to make sure another thread can't nuke the connection object while it is being used by another thread. Added a new file to the lldb/test/load_unload test that causes the test a.out file to link to the libd.dylib file all the time. This will allow us to test using the DYLD_LIBRARY_PATH environment variable after moving libd.dylib somewhere else. llvm-svn: 121745
2010-12-14 10:59:59 +08:00
m_local_variables.reset(new ClangExpressionVariableList());
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 dwarf_error = parser.MakeDWARF ();
if (dwarf_error.Success())
{
if (log)
log->Printf("Code can be interpreted.");
Fixed object lifetimes in ClangExpressionDeclMap so that it is not referring to potentially stale state during IR execution. This was done by introducing modular state (like ClangExpressionVariable) where groups of state variables have well-defined lifetimes: - m_parser_vars are specific to parsing, and only exist between calls to WillParse() and DidParse(). - m_struct_vars survive for the entire execution of the ClangExpressionDeclMap because they provide the template for a materialized set of expression variables. - m_material_vars are specific to a single instance of materialization, and only exist between calls to Materialize() and Dematerialize(). I also removed unnecessary references to long- lived state that really didn't need to be referred to at all, and also introduced several assert()s that helped me diagnose a few bugs (fixed too). llvm-svn: 120778
2010-12-03 09:38:59 +08:00
m_expr_decl_map->DidParse();
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 true;
}
//////////////////////////////////
// JIT the output of the parser
//
m_dwarf_opcodes.reset();
Made expressions that are just casts of pointer variables be evaluated statically. Also fixed a bug that caused the results of statically-evaluated expressions to be materialized improperly. This bug also removes some duplicate code. llvm-svn: 131042
2011-05-07 09:06:41 +08:00
Error jit_error = parser.MakeJIT (m_jit_alloc, m_jit_start_addr, m_jit_end_addr, exe_ctx, m_const_result, 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
Fixed object lifetimes in ClangExpressionDeclMap so that it is not referring to potentially stale state during IR execution. This was done by introducing modular state (like ClangExpressionVariable) where groups of state variables have well-defined lifetimes: - m_parser_vars are specific to parsing, and only exist between calls to WillParse() and DidParse(). - m_struct_vars survive for the entire execution of the ClangExpressionDeclMap because they provide the template for a materialized set of expression variables. - m_material_vars are specific to a single instance of materialization, and only exist between calls to Materialize() and Dematerialize(). I also removed unnecessary references to long- lived state that really didn't need to be referred to at all, and also introduced several assert()s that helped me diagnose a few bugs (fixed too). llvm-svn: 120778
2010-12-03 09:38:59 +08:00
m_expr_decl_map->DidParse();
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 (jit_error.Success())
{
Make expressions clean up their JIT'ed code allocation. llvm-svn: 123855
2011-01-20 07:00:49 +08:00
if (exe_ctx.process && m_jit_alloc != LLDB_INVALID_ADDRESS)
m_jit_process_sp = exe_ctx.process->GetSP();
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 true;
}
else
{
error_stream.Printf ("error: expression can't be interpreted or run\n", num_errors);
return false;
}
}
bool
Added support for breakpoint conditions. I also had to separate the "run the expression" part of ClangFunction::Execute from the "Gather the expression result" so that in the case of the Breakpoint condition I can move the condition evaluation into the normal thread plan processing. Also added support for remembering the "last set breakpoint" so that "break modify" will act on the last set breakpoint. llvm-svn: 116542
2010-10-15 07:45:03 +08:00
ClangUserExpression::PrepareToExecuteJITExpression (Stream &error_stream,
Fixed a silly bug that was causing the "this" pointer to be passed improperly to expressions in certain cases. llvm-svn: 116884
2010-10-20 07:57:21 +08:00
ExecutionContext &exe_ctx,
lldb::addr_t &struct_address,
Bugfixes for the new "self" pointer handling. Specifically, the code to pass the _cmd pointer has been improved, and _cmd is now set to the value of _cmd for the current context, as opposed to being simply NULL. llvm-svn: 121739
2010-12-14 08:42:36 +08:00
lldb::addr_t &object_ptr,
lldb::addr_t &cmd_ptr)
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
{
Modified all logging calls to hand out shared pointers to make sure we don't crash if we disable logging when some code already has a copy of the logger. Prior to this fix, logs were handed out as pointers and if they were held onto while a log got disabled, then it could cause a crash. Now all logs are handed out as shared pointers so this problem shouldn't happen anymore. We are also using our new shared pointers that put the shared pointer count and the object into the same allocation for a tad better performance. llvm-svn: 118319
2010-11-06 09:53:30 +08:00
lldb::LogSP log(lldb_private::GetLogIfAllCategoriesSet (LIBLLDB_LOG_EXPRESSIONS));
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
Make expressions clean up their JIT'ed code allocation. llvm-svn: 123855
2011-01-20 07:00:49 +08:00
if (m_jit_start_addr != LLDB_INVALID_ADDRESS)
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 materialize_error;
Added support for generating expressions that have access to the members of the Objective-C self object. The approach we take is to generate the method as a @category on top of the self object, and to pass the "self" pointer to it. (_cmd is currently NULL.) Most changes are in ClangExpressionDeclMap, but the change that adds support to the ABIs to pass _cmd touches a fair amount of code. llvm-svn: 121722
2010-12-14 06:46:15 +08:00
if (m_needs_object_ptr)
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
{
Added support for generating expressions that have access to the members of the Objective-C self object. The approach we take is to generate the method as a @category on top of the self object, and to pass the "self" pointer to it. (_cmd is currently NULL.) Most changes are in ClangExpressionDeclMap, but the change that adds support to the ABIs to pass _cmd touches a fair amount of code. llvm-svn: 121722
2010-12-14 06:46:15 +08:00
ConstString object_name;
if (m_cplusplus)
{
object_name.SetCString("this");
}
else if (m_objectivec)
{
object_name.SetCString("self");
}
else
{
error_stream.Printf("Need object pointer but don't know the language\n");
return false;
}
if (!(m_expr_decl_map->GetObjectPointer(object_ptr, object_name, exe_ctx, materialize_error)))
{
error_stream.Printf("Couldn't get required object pointer: %s\n", materialize_error.AsCString());
return false;
}
Bugfixes for the new "self" pointer handling. Specifically, the code to pass the _cmd pointer has been improved, and _cmd is now set to the value of _cmd for the current context, as opposed to being simply NULL. llvm-svn: 121739
2010-12-14 08:42:36 +08:00
if (m_objectivec)
{
ConstString cmd_name("_cmd");
if (!(m_expr_decl_map->GetObjectPointer(cmd_ptr, cmd_name, exe_ctx, materialize_error, true)))
{
error_stream.Printf("Couldn't get required object pointer: %s\n", materialize_error.AsCString());
return false;
}
}
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
}
Fixed object lifetimes in ClangExpressionDeclMap so that it is not referring to potentially stale state during IR execution. This was done by introducing modular state (like ClangExpressionVariable) where groups of state variables have well-defined lifetimes: - m_parser_vars are specific to parsing, and only exist between calls to WillParse() and DidParse(). - m_struct_vars survive for the entire execution of the ClangExpressionDeclMap because they provide the template for a materialized set of expression variables. - m_material_vars are specific to a single instance of materialization, and only exist between calls to Materialize() and Dematerialize(). I also removed unnecessary references to long- lived state that really didn't need to be referred to at all, and also introduced several assert()s that helped me diagnose a few bugs (fixed too). llvm-svn: 120778
2010-12-03 09:38:59 +08:00
if (!m_expr_decl_map->Materialize(exe_ctx, struct_address, materialize_error))
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
{
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
error_stream.Printf("Couldn't materialize struct: %s\n", materialize_error.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
return false;
}
Thread safety changes in debugserver and also in the process GDB remote plugin. I added support for asking if the GDB remote server supports thread suffixes for packets that should be thread specific (register read/write packets) because the way the GDB remote protocol does it right now is to have a notion of a current thread for register and memory reads/writes (set via the "$Hg%x" packet) and a current thread for running ("$Hc%x"). Now we ask the remote GDB server if it supports adding the thread ID to the register packets and we enable that feature in LLDB if supported. This stops us from having to send a bunch of packets that update the current thread ID to some value which is prone to error, or extra packets. llvm-svn: 123762
2011-01-19 03:36:39 +08:00
#if 0
// jingham: look here
StreamFile logfile ("/tmp/exprs.txt", "a");
Make expressions clean up their JIT'ed code allocation. llvm-svn: 123855
2011-01-20 07:00:49 +08:00
logfile.Printf("0x%16.16llx: thread = 0x%4.4x, expr = '%s'\n", m_jit_start_addr, exe_ctx.thread ? exe_ctx.thread->GetID() : -1, m_expr_text.c_str());
Thread safety changes in debugserver and also in the process GDB remote plugin. I added support for asking if the GDB remote server supports thread suffixes for packets that should be thread specific (register read/write packets) because the way the GDB remote protocol does it right now is to have a notion of a current thread for register and memory reads/writes (set via the "$Hg%x" packet) and a current thread for running ("$Hc%x"). Now we ask the remote GDB server if it supports adding the thread ID to the register packets and we enable that feature in LLDB if supported. This stops us from having to send a bunch of packets that update the current thread ID to some value which is prone to error, or extra packets. llvm-svn: 123762
2011-01-19 03:36:39 +08:00
#endif
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 (log)
{
More logging for use in debugging the interactions between clients of the LLDB API and the expression parser. llvm-svn: 121193
2010-12-08 06:55:01 +08:00
log->Printf("-- [ClangUserExpression::PrepareToExecuteJITExpression] Materializing for execution --");
Logging improvements to help identify major events in LLDB expression execution. We also now print the argument structure after execution, to allow us to verify that the expression did indeed execute correctly. llvm-svn: 121126
2010-12-07 18:00:20 +08:00
Make expressions clean up their JIT'ed code allocation. llvm-svn: 123855
2011-01-20 07:00:49 +08:00
log->Printf(" Function address : 0x%llx", (uint64_t)m_jit_start_addr);
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 (m_needs_object_ptr)
Logging improvements to help identify major events in LLDB expression execution. We also now print the argument structure after execution, to allow us to verify that the expression did indeed execute correctly. llvm-svn: 121126
2010-12-07 18:00:20 +08:00
log->Printf(" Object pointer : 0x%llx", (uint64_t)object_ptr);
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
Logging improvements to help identify major events in LLDB expression execution. We also now print the argument structure after execution, to allow us to verify that the expression did indeed execute correctly. llvm-svn: 121126
2010-12-07 18:00:20 +08:00
log->Printf(" Structure address : 0x%llx", (uint64_t)struct_address);
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
StreamString args;
Error dump_error;
Bugfixes to the expression parser. Fixes include: - If you put a semicolon at the end of an expression, this no longer causes the expression parser to error out. This was a two-part fix: first, ClangExpressionDeclMap::Materialize now handles an empty struct (such as when there is no return value); second, ASTResultSynthesizer walks backward from the end of the ASTs until it reaches something that's not a NullStmt. - ClangExpressionVariable now properly byte-swaps when printing itself. - ClangUtilityFunction now cleans up after itself when it's done compiling itself. - Utility functions can now use external functions just like user expressions. - If you end your expression with a statement that does not return a value, the expression now runs correctly anyway. Also, added the beginnings of an Objective-C object validator function, which is neither installed nor used as yet. llvm-svn: 113789
2010-09-14 05:34:21 +08:00
if (struct_address)
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
{
Fixed object lifetimes in ClangExpressionDeclMap so that it is not referring to potentially stale state during IR execution. This was done by introducing modular state (like ClangExpressionVariable) where groups of state variables have well-defined lifetimes: - m_parser_vars are specific to parsing, and only exist between calls to WillParse() and DidParse(). - m_struct_vars survive for the entire execution of the ClangExpressionDeclMap because they provide the template for a materialized set of expression variables. - m_material_vars are specific to a single instance of materialization, and only exist between calls to Materialize() and Dematerialize(). I also removed unnecessary references to long- lived state that really didn't need to be referred to at all, and also introduced several assert()s that helped me diagnose a few bugs (fixed too). llvm-svn: 120778
2010-12-03 09:38:59 +08:00
if (!m_expr_decl_map->DumpMaterializedStruct(exe_ctx, args, dump_error))
Bugfixes to the expression parser. Fixes include: - If you put a semicolon at the end of an expression, this no longer causes the expression parser to error out. This was a two-part fix: first, ClangExpressionDeclMap::Materialize now handles an empty struct (such as when there is no return value); second, ASTResultSynthesizer walks backward from the end of the ASTs until it reaches something that's not a NullStmt. - ClangExpressionVariable now properly byte-swaps when printing itself. - ClangUtilityFunction now cleans up after itself when it's done compiling itself. - Utility functions can now use external functions just like user expressions. - If you end your expression with a statement that does not return a value, the expression now runs correctly anyway. Also, added the beginnings of an Objective-C object validator function, which is neither installed nor used as yet. llvm-svn: 113789
2010-09-14 05:34:21 +08:00
{
Logging improvements to help identify major events in LLDB expression execution. We also now print the argument structure after execution, to allow us to verify that the expression did indeed execute correctly. llvm-svn: 121126
2010-12-07 18:00:20 +08:00
log->Printf(" Couldn't extract variable values : %s", dump_error.AsCString("unknown error"));
Bugfixes to the expression parser. Fixes include: - If you put a semicolon at the end of an expression, this no longer causes the expression parser to error out. This was a two-part fix: first, ClangExpressionDeclMap::Materialize now handles an empty struct (such as when there is no return value); second, ASTResultSynthesizer walks backward from the end of the ASTs until it reaches something that's not a NullStmt. - ClangExpressionVariable now properly byte-swaps when printing itself. - ClangUtilityFunction now cleans up after itself when it's done compiling itself. - Utility functions can now use external functions just like user expressions. - If you end your expression with a statement that does not return a value, the expression now runs correctly anyway. Also, added the beginnings of an Objective-C object validator function, which is neither installed nor used as yet. llvm-svn: 113789
2010-09-14 05:34:21 +08:00
}
else
{
Logging improvements to help identify major events in LLDB expression execution. We also now print the argument structure after execution, to allow us to verify that the expression did indeed execute correctly. llvm-svn: 121126
2010-12-07 18:00:20 +08:00
log->Printf(" Structure contents:\n%s", args.GetData());
Bugfixes to the expression parser. Fixes include: - If you put a semicolon at the end of an expression, this no longer causes the expression parser to error out. This was a two-part fix: first, ClangExpressionDeclMap::Materialize now handles an empty struct (such as when there is no return value); second, ASTResultSynthesizer walks backward from the end of the ASTs until it reaches something that's not a NullStmt. - ClangExpressionVariable now properly byte-swaps when printing itself. - ClangUtilityFunction now cleans up after itself when it's done compiling itself. - Utility functions can now use external functions just like user expressions. - If you end your expression with a statement that does not return a value, the expression now runs correctly anyway. Also, added the beginnings of an Objective-C object validator function, which is neither installed nor used as yet. llvm-svn: 113789
2010-09-14 05:34:21 +08:00
}
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
}
}
Added support for breakpoint conditions. I also had to separate the "run the expression" part of ClangFunction::Execute from the "Gather the expression result" so that in the case of the Breakpoint condition I can move the condition evaluation into the normal thread plan processing. Also added support for remembering the "last set breakpoint" so that "break modify" will act on the last set breakpoint. llvm-svn: 116542
2010-10-15 07:45:03 +08:00
}
return true;
}
ThreadPlan *
ClangUserExpression::GetThreadPlanToExecuteJITExpression (Stream &error_stream,
Implemented a major overhaul of the way variables are handled by LLDB. Instead of being materialized into the input structure passed to the expression, variables are left in place and pointers to them are materialzied into the structure. Variables not resident in memory (notably, registers) get temporary memory regions allocated for them. Persistent variables are the most complex part of this, because they are made in various ways and there are different expectations about their lifetime. Persistent variables now have flags indicating their status and what the expectations for longevity are. They can be marked as residing in target memory permanently -- this is the default for result variables from expressions entered on the command line and for explicitly declared persistent variables (but more on that below). Other result variables have their memory freed. Some major improvements resulting from this include being able to properly take the address of variables, better and cleaner support for functions that return references, and cleaner C++ support in general. One problem that remains is the problem of explicitly declared persistent variables; I have not yet implemented the code that makes references to them into indirect references, so currently materialization and dematerialization of these variables is broken. llvm-svn: 123371
2011-01-13 16:53:35 +08:00
ExecutionContext &exe_ctx)
Added support for breakpoint conditions. I also had to separate the "run the expression" part of ClangFunction::Execute from the "Gather the expression result" so that in the case of the Breakpoint condition I can move the condition evaluation into the normal thread plan processing. Also added support for remembering the "last set breakpoint" so that "break modify" will act on the last set breakpoint. llvm-svn: 116542
2010-10-15 07:45:03 +08:00
{
lldb::addr_t struct_address;
lldb::addr_t object_ptr = NULL;
Added support for generating expressions that have access to the members of the Objective-C self object. The approach we take is to generate the method as a @category on top of the self object, and to pass the "self" pointer to it. (_cmd is currently NULL.) Most changes are in ClangExpressionDeclMap, but the change that adds support to the ABIs to pass _cmd touches a fair amount of code. llvm-svn: 121722
2010-12-14 06:46:15 +08:00
lldb::addr_t cmd_ptr = NULL;
Added support for breakpoint conditions. I also had to separate the "run the expression" part of ClangFunction::Execute from the "Gather the expression result" so that in the case of the Breakpoint condition I can move the condition evaluation into the normal thread plan processing. Also added support for remembering the "last set breakpoint" so that "break modify" will act on the last set breakpoint. llvm-svn: 116542
2010-10-15 07:45:03 +08:00
Bugfixes for the new "self" pointer handling. Specifically, the code to pass the _cmd pointer has been improved, and _cmd is now set to the value of _cmd for the current context, as opposed to being simply NULL. llvm-svn: 121739
2010-12-14 08:42:36 +08:00
PrepareToExecuteJITExpression (error_stream, exe_ctx, struct_address, object_ptr, cmd_ptr);
Added support for breakpoint conditions. I also had to separate the "run the expression" part of ClangFunction::Execute from the "Gather the expression result" so that in the case of the Breakpoint condition I can move the condition evaluation into the normal thread plan processing. Also added support for remembering the "last set breakpoint" so that "break modify" will act on the last set breakpoint. llvm-svn: 116542
2010-10-15 07:45:03 +08:00
Moved the code in ClangUserExpression that set up & ran the thread plan with timeouts, and restarting with all threads into a utility function in Process. This required a bunch of renaming. Added a ThreadPlanCallUserExpression that differs from ThreadPlanCallFunction in that it holds onto a shared pointer to its ClangUserExpression so that can't go away before the thread plan is done using it. Fixed the stop message when you hit a breakpoint while running a user expression so it is more obvious what has happened. llvm-svn: 120386
2010-11-30 10:22:11 +08:00
// FIXME: This should really return a ThreadPlanCallUserExpression, in order to make sure that we don't release the
// ClangUserExpression resources before the thread plan finishes execution in the target. But because we are
Added support for generating expressions that have access to the members of the Objective-C self object. The approach we take is to generate the method as a @category on top of the self object, and to pass the "self" pointer to it. (_cmd is currently NULL.) Most changes are in ClangExpressionDeclMap, but the change that adds support to the ABIs to pass _cmd touches a fair amount of code. llvm-svn: 121722
2010-12-14 06:46:15 +08:00
// forcing unwind_on_error to be true here, in practical terms that can't happen.
Added support for breakpoint conditions. I also had to separate the "run the expression" part of ClangFunction::Execute from the "Gather the expression result" so that in the case of the Breakpoint condition I can move the condition evaluation into the normal thread plan processing. Also added support for remembering the "last set breakpoint" so that "break modify" will act on the last set breakpoint. llvm-svn: 116542
2010-10-15 07:45:03 +08:00
return ClangFunction::GetThreadPlanToCallFunction (exe_ctx,
Make expressions clean up their JIT'ed code allocation. llvm-svn: 123855
2011-01-20 07:00:49 +08:00
m_jit_start_addr,
Whitespace fix. llvm-svn: 120520
2010-12-01 09:28:23 +08:00
struct_address,
error_stream,
true,
true,
Added support for generating expressions that have access to the members of the Objective-C self object. The approach we take is to generate the method as a @category on top of the self object, and to pass the "self" pointer to it. (_cmd is currently NULL.) Most changes are in ClangExpressionDeclMap, but the change that adds support to the ABIs to pass _cmd touches a fair amount of code. llvm-svn: 121722
2010-12-14 06:46:15 +08:00
(m_needs_object_ptr ? &object_ptr : NULL),
(m_needs_object_ptr && m_objectivec) ? &cmd_ptr : NULL);
Added support for breakpoint conditions. I also had to separate the "run the expression" part of ClangFunction::Execute from the "Gather the expression result" so that in the case of the Breakpoint condition I can move the condition evaluation into the normal thread plan processing. Also added support for remembering the "last set breakpoint" so that "break modify" will act on the last set breakpoint. llvm-svn: 116542
2010-10-15 07:45:03 +08:00
}
bool
ClangUserExpression::FinalizeJITExecution (Stream &error_stream,
ExecutionContext &exe_ctx,
Fixed a bug in which expression-local variables were treated as being permanently resident in target memory. In fact, since the expression's stack frame is deleted and potentially re-used after the expression completes, the variables need to be treated as being freeze-dried. llvm-svn: 131104
2011-05-10 06:04:36 +08:00
lldb::ClangExpressionVariableSP &result,
lldb::addr_t function_stack_pointer)
Added support for breakpoint conditions. I also had to separate the "run the expression" part of ClangFunction::Execute from the "Gather the expression result" so that in the case of the Breakpoint condition I can move the condition evaluation into the normal thread plan processing. Also added support for remembering the "last set breakpoint" so that "break modify" will act on the last set breakpoint. llvm-svn: 116542
2010-10-15 07:45:03 +08:00
{
Error expr_error;
Logging improvements to help identify major events in LLDB expression execution. We also now print the argument structure after execution, to allow us to verify that the expression did indeed execute correctly. llvm-svn: 121126
2010-12-07 18:00:20 +08:00
lldb::LogSP log(lldb_private::GetLogIfAllCategoriesSet (LIBLLDB_LOG_EXPRESSIONS));
if (log)
{
More logging for use in debugging the interactions between clients of the LLDB API and the expression parser. llvm-svn: 121193
2010-12-08 06:55:01 +08:00
log->Printf("-- [ClangUserExpression::FinalizeJITExecution] Dematerializing after execution --");
Logging improvements to help identify major events in LLDB expression execution. We also now print the argument structure after execution, to allow us to verify that the expression did indeed execute correctly. llvm-svn: 121126
2010-12-07 18:00:20 +08:00
StreamString args;
Error dump_error;
if (!m_expr_decl_map->DumpMaterializedStruct(exe_ctx, args, dump_error))
{
log->Printf(" Couldn't extract variable values : %s", dump_error.AsCString("unknown error"));
}
else
{
log->Printf(" Structure contents:\n%s", args.GetData());
}
}
Fixed a bug in which expression-local variables were treated as being permanently resident in target memory. In fact, since the expression's stack frame is deleted and potentially re-used after the expression completes, the variables need to be treated as being freeze-dried. llvm-svn: 131104
2011-05-10 06:04:36 +08:00
lldb::addr_t function_stack_bottom = function_stack_pointer - Host::GetPageSize();
Logging improvements to help identify major events in LLDB expression execution. We also now print the argument structure after execution, to allow us to verify that the expression did indeed execute correctly. llvm-svn: 121126
2010-12-07 18:00:20 +08:00
Fixed a bug in which expression-local variables were treated as being permanently resident in target memory. In fact, since the expression's stack frame is deleted and potentially re-used after the expression completes, the variables need to be treated as being freeze-dried. llvm-svn: 131104
2011-05-10 06:04:36 +08:00
if (!m_expr_decl_map->Dematerialize(exe_ctx, result, function_stack_pointer, function_stack_bottom, expr_error))
Added support for breakpoint conditions. I also had to separate the "run the expression" part of ClangFunction::Execute from the "Gather the expression result" so that in the case of the Breakpoint condition I can move the condition evaluation into the normal thread plan processing. Also added support for remembering the "last set breakpoint" so that "break modify" will act on the last set breakpoint. llvm-svn: 116542
2010-10-15 07:45:03 +08:00
{
error_stream.Printf ("Couldn't dematerialize struct : %s\n", expr_error.AsCString("unknown error"));
return false;
}
return true;
}
Fixed the LLDB build so that we can have private types, private enums and public types and public enums. This was done to keep the SWIG stuff from parsing all sorts of enums and types that weren't needed, and allows us to abstract our API better. llvm-svn: 128239
2011-03-25 05:19:54 +08:00
ExecutionResults
Added support for breakpoint conditions. I also had to separate the "run the expression" part of ClangFunction::Execute from the "Gather the expression result" so that in the case of the Breakpoint condition I can move the condition evaluation into the normal thread plan processing. Also added support for remembering the "last set breakpoint" so that "break modify" will act on the last set breakpoint. llvm-svn: 116542
2010-10-15 07:45:03 +08:00
ClangUserExpression::Execute (Stream &error_stream,
ExecutionContext &exe_ctx,
Added the equivalent of gdb's "unwind-on-signal" to the expression command, and a parameter to control it in ClangUserExpression, and on down to ClangFunction. llvm-svn: 118290
2010-11-06 03:25:48 +08:00
bool discard_on_error,
Moved the code in ClangUserExpression that set up & ran the thread plan with timeouts, and restarting with all threads into a utility function in Process. This required a bunch of renaming. Added a ThreadPlanCallUserExpression that differs from ThreadPlanCallFunction in that it holds onto a shared pointer to its ClangUserExpression so that can't go away before the thread plan is done using it. Fixed the stop message when you hit a breakpoint while running a user expression so it is more obvious what has happened. llvm-svn: 120386
2010-11-30 10:22:11 +08:00
ClangUserExpression::ClangUserExpressionSP &shared_ptr_to_me,
Modified LLDB expressions to not have to JIT and run code just to see variable values or persistent expression variables. Now if an expression consists of a value that is a child of a variable, or of a persistent variable only, we will create a value object for it and make a ValueObjectConstResult from it to freeze the value (for program variables only, not persistent variables) and avoid running JITed code. For everything else we still parse up and JIT code and run it in the inferior. There was also a lot of clean up in the expression code. I made the ClangExpressionVariables be stored in collections of shared pointers instead of in collections of objects. This will help stop a lot of copy constructors on these large objects and also cleans up the code considerably. The persistent clang expression variables were moved over to the Target to ensure they persist across process executions. Added the ability for lldb_private::Target objects to evaluate expressions. We want to evaluate expressions at the target level in case we aren't running yet, or we have just completed running. We still want to be able to access the persistent expression variables between runs, and also evaluate constant expressions. Added extra logging to the dynamic loader plug-in for MacOSX. ModuleList objects can now dump their contents with the UUID, arch and full paths being logged with appropriate prefix values. Thread hardened the Communication class a bit by making the connection auto_ptr member into a shared pointer member and then making a local copy of the shared pointer in each method that uses it to make sure another thread can't nuke the connection object while it is being used by another thread. Added a new file to the lldb/test/load_unload test that causes the test a.out file to link to the libd.dylib file all the time. This will allow us to test using the DYLD_LIBRARY_PATH environment variable after moving libd.dylib somewhere else. llvm-svn: 121745
2010-12-14 10:59:59 +08:00
lldb::ClangExpressionVariableSP &result)
Added support for breakpoint conditions. I also had to separate the "run the expression" part of ClangFunction::Execute from the "Gather the expression result" so that in the case of the Breakpoint condition I can move the condition evaluation into the normal thread plan processing. Also added support for remembering the "last set breakpoint" so that "break modify" will act on the last set breakpoint. llvm-svn: 116542
2010-10-15 07:45:03 +08:00
{
Make a few log messages come out in "log enable lldb step" as well as "log enable lldb expression". llvm-svn: 123784
2011-01-19 06:20:08 +08:00
// The expression log is quite verbose, and if you're just tracking the execution of the
// expression, it's quite convenient to have these logs come out with the STEP log as well.
lldb::LogSP log(lldb_private::GetLogIfAnyCategoriesSet (LIBLLDB_LOG_EXPRESSIONS | LIBLLDB_LOG_STEP));
Logging improvements to help identify major events in LLDB expression execution. We also now print the argument structure after execution, to allow us to verify that the expression did indeed execute correctly. llvm-svn: 121126
2010-12-07 18:00:20 +08:00
Added support for breakpoint conditions. I also had to separate the "run the expression" part of ClangFunction::Execute from the "Gather the expression result" so that in the case of the Breakpoint condition I can move the condition evaluation into the normal thread plan processing. Also added support for remembering the "last set breakpoint" so that "break modify" will act on the last set breakpoint. llvm-svn: 116542
2010-10-15 07:45:03 +08:00
if (m_dwarf_opcodes.get())
{
// TODO execute the JITted opcodes
error_stream.Printf("We don't currently support executing DWARF expressions");
Fixed the LLDB build so that we can have private types, private enums and public types and public enums. This was done to keep the SWIG stuff from parsing all sorts of enums and types that weren't needed, and allows us to abstract our API better. llvm-svn: 128239
2011-03-25 05:19:54 +08:00
return eExecutionSetupError;
Added support for breakpoint conditions. I also had to separate the "run the expression" part of ClangFunction::Execute from the "Gather the expression result" so that in the case of the Breakpoint condition I can move the condition evaluation into the normal thread plan processing. Also added support for remembering the "last set breakpoint" so that "break modify" will act on the last set breakpoint. llvm-svn: 116542
2010-10-15 07:45:03 +08:00
}
Make expressions clean up their JIT'ed code allocation. llvm-svn: 123855
2011-01-20 07:00:49 +08:00
else if (m_jit_start_addr != LLDB_INVALID_ADDRESS)
Added support for breakpoint conditions. I also had to separate the "run the expression" part of ClangFunction::Execute from the "Gather the expression result" so that in the case of the Breakpoint condition I can move the condition evaluation into the normal thread plan processing. Also added support for remembering the "last set breakpoint" so that "break modify" will act on the last set breakpoint. llvm-svn: 116542
2010-10-15 07:45:03 +08:00
{
lldb::addr_t struct_address;
lldb::addr_t object_ptr = NULL;
Added support for generating expressions that have access to the members of the Objective-C self object. The approach we take is to generate the method as a @category on top of the self object, and to pass the "self" pointer to it. (_cmd is currently NULL.) Most changes are in ClangExpressionDeclMap, but the change that adds support to the ABIs to pass _cmd touches a fair amount of code. llvm-svn: 121722
2010-12-14 06:46:15 +08:00
lldb::addr_t cmd_ptr = NULL;
Added support for breakpoint conditions. I also had to separate the "run the expression" part of ClangFunction::Execute from the "Gather the expression result" so that in the case of the Breakpoint condition I can move the condition evaluation into the normal thread plan processing. Also added support for remembering the "last set breakpoint" so that "break modify" will act on the last set breakpoint. llvm-svn: 116542
2010-10-15 07:45:03 +08:00
Bugfixes for the new "self" pointer handling. Specifically, the code to pass the _cmd pointer has been improved, and _cmd is now set to the value of _cmd for the current context, as opposed to being simply NULL. llvm-svn: 121739
2010-12-14 08:42:36 +08:00
if (!PrepareToExecuteJITExpression (error_stream, exe_ctx, struct_address, object_ptr, cmd_ptr))
Fixed the LLDB build so that we can have private types, private enums and public types and public enums. This was done to keep the SWIG stuff from parsing all sorts of enums and types that weren't needed, and allows us to abstract our API better. llvm-svn: 128239
2011-03-25 05:19:54 +08:00
return eExecutionSetupError;
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
Added the equivalent of gdb's "unwind-on-signal" to the expression command, and a parameter to control it in ClangUserExpression, and on down to ClangFunction. llvm-svn: 118290
2010-11-06 03:25:48 +08:00
const bool stop_others = true;
const bool try_all_threads = 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
Make expressions clean up their JIT'ed code allocation. llvm-svn: 123855
2011-01-20 07:00:49 +08:00
Address wrapper_address (NULL, m_jit_start_addr);
Added support for generating expressions that have access to the members of the Objective-C self object. The approach we take is to generate the method as a @category on top of the self object, and to pass the "self" pointer to it. (_cmd is currently NULL.) Most changes are in ClangExpressionDeclMap, but the change that adds support to the ABIs to pass _cmd touches a fair amount of code. llvm-svn: 121722
2010-12-14 06:46:15 +08:00
lldb::ThreadPlanSP call_plan_sp(new ThreadPlanCallUserExpression (*(exe_ctx.thread),
wrapper_address,
struct_address,
stop_others,
discard_on_error,
(m_needs_object_ptr ? &object_ptr : NULL),
((m_needs_object_ptr && m_objectivec) ? &cmd_ptr : NULL),
shared_ptr_to_me));
Moved the code in ClangUserExpression that set up & ran the thread plan with timeouts, and restarting with all threads into a utility function in Process. This required a bunch of renaming. Added a ThreadPlanCallUserExpression that differs from ThreadPlanCallFunction in that it holds onto a shared pointer to its ClangUserExpression so that can't go away before the thread plan is done using it. Fixed the stop message when you hit a breakpoint while running a user expression so it is more obvious what has happened. llvm-svn: 120386
2010-11-30 10:22:11 +08:00
if (call_plan_sp == NULL || !call_plan_sp->ValidatePlan (NULL))
Fixed the LLDB build so that we can have private types, private enums and public types and public enums. This was done to keep the SWIG stuff from parsing all sorts of enums and types that weren't needed, and allows us to abstract our API better. llvm-svn: 128239
2011-03-25 05:19:54 +08:00
return eExecutionSetupError;
Fixed a bug in which expression-local variables were treated as being permanently resident in target memory. In fact, since the expression's stack frame is deleted and potentially re-used after the expression completes, the variables need to be treated as being freeze-dried. llvm-svn: 131104
2011-05-10 06:04:36 +08:00
lldb::addr_t function_stack_pointer = static_cast<ThreadPlanCallFunction *>(call_plan_sp.get())->GetFunctionStackPointer();
Moved the code in ClangUserExpression that set up & ran the thread plan with timeouts, and restarting with all threads into a utility function in Process. This required a bunch of renaming. Added a ThreadPlanCallUserExpression that differs from ThreadPlanCallFunction in that it holds onto a shared pointer to its ClangUserExpression so that can't go away before the thread plan is done using it. Fixed the stop message when you hit a breakpoint while running a user expression so it is more obvious what has happened. llvm-svn: 120386
2010-11-30 10:22:11 +08:00
call_plan_sp->SetPrivate(true);
Took the timeout for a ClangUserExpression down from a 10 second timeout to 500 ms. Make MachThreadList more threadsafe. Added code to make sure the thread register state was properly flushed for x86_64. Fixed an missing return code for the current thread in the new thread suffix code. Improved debugserver logging. llvm-svn: 123815
2011-01-19 15:54:15 +08:00
uint32_t single_thread_timeout_usec = 500000;
Logging improvements to help identify major events in LLDB expression execution. We also now print the argument structure after execution, to allow us to verify that the expression did indeed execute correctly. llvm-svn: 121126
2010-12-07 18:00:20 +08:00
if (log)
More logging for use in debugging the interactions between clients of the LLDB API and the expression parser. llvm-svn: 121193
2010-12-08 06:55:01 +08:00
log->Printf("-- [ClangUserExpression::Execute] Execution of expression begins --");
Logging improvements to help identify major events in LLDB expression execution. We also now print the argument structure after execution, to allow us to verify that the expression did indeed execute correctly. llvm-svn: 121126
2010-12-07 18:00:20 +08:00
Fixed the LLDB build so that we can have private types, private enums and public types and public enums. This was done to keep the SWIG stuff from parsing all sorts of enums and types that weren't needed, and allows us to abstract our API better. llvm-svn: 128239
2011-03-25 05:19:54 +08:00
ExecutionResults execution_result = exe_ctx.process->RunThreadPlan (exe_ctx,
Fixed a bug in which expression-local variables were treated as being permanently resident in target memory. In fact, since the expression's stack frame is deleted and potentially re-used after the expression completes, the variables need to be treated as being freeze-dried. llvm-svn: 131104
2011-05-10 06:04:36 +08:00
call_plan_sp,
stop_others,
try_all_threads,
discard_on_error,
single_thread_timeout_usec,
error_stream);
Logging improvements to help identify major events in LLDB expression execution. We also now print the argument structure after execution, to allow us to verify that the expression did indeed execute correctly. llvm-svn: 121126
2010-12-07 18:00:20 +08:00
if (log)
More logging for use in debugging the interactions between clients of the LLDB API and the expression parser. llvm-svn: 121193
2010-12-08 06:55:01 +08:00
log->Printf("-- [ClangUserExpression::Execute] Execution of expression completed --");
Moved the code in ClangUserExpression that set up & ran the thread plan with timeouts, and restarting with all threads into a utility function in Process. This required a bunch of renaming. Added a ThreadPlanCallUserExpression that differs from ThreadPlanCallFunction in that it holds onto a shared pointer to its ClangUserExpression so that can't go away before the thread plan is done using it. Fixed the stop message when you hit a breakpoint while running a user expression so it is more obvious what has happened. llvm-svn: 120386
2010-11-30 10:22:11 +08:00
Fixed the LLDB build so that we can have private types, private enums and public types and public enums. This was done to keep the SWIG stuff from parsing all sorts of enums and types that weren't needed, and allows us to abstract our API better. llvm-svn: 128239
2011-03-25 05:19:54 +08:00
if (execution_result == eExecutionInterrupted)
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
{
Moved the code in ClangUserExpression that set up & ran the thread plan with timeouts, and restarting with all threads into a utility function in Process. This required a bunch of renaming. Added a ThreadPlanCallUserExpression that differs from ThreadPlanCallFunction in that it holds onto a shared pointer to its ClangUserExpression so that can't go away before the thread plan is done using it. Fixed the stop message when you hit a breakpoint while running a user expression so it is more obvious what has happened. llvm-svn: 120386
2010-11-30 10:22:11 +08:00
if (discard_on_error)
error_stream.Printf ("Expression execution was interrupted. The process has been returned to the state before execution.");
else
error_stream.Printf ("Expression execution was interrupted. The process has been left at the point where it was interrupted.");
return execution_result;
}
Fixed the LLDB build so that we can have private types, private enums and public types and public enums. This was done to keep the SWIG stuff from parsing all sorts of enums and types that weren't needed, and allows us to abstract our API better. llvm-svn: 128239
2011-03-25 05:19:54 +08:00
else if (execution_result != eExecutionCompleted)
Moved the code in ClangUserExpression that set up & ran the thread plan with timeouts, and restarting with all threads into a utility function in Process. This required a bunch of renaming. Added a ThreadPlanCallUserExpression that differs from ThreadPlanCallFunction in that it holds onto a shared pointer to its ClangUserExpression so that can't go away before the thread plan is done using it. Fixed the stop message when you hit a breakpoint while running a user expression so it is more obvious what has happened. llvm-svn: 120386
2010-11-30 10:22:11 +08:00
{
error_stream.Printf ("Couldn't execute function; result was %s\n", Process::ExecutionResultAsCString (execution_result));
return execution_result;
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
}
Fixed a bug in which expression-local variables were treated as being permanently resident in target memory. In fact, since the expression's stack frame is deleted and potentially re-used after the expression completes, the variables need to be treated as being freeze-dried. llvm-svn: 131104
2011-05-10 06:04:36 +08:00
if (FinalizeJITExecution (error_stream, exe_ctx, result, function_stack_pointer))
Fixed the LLDB build so that we can have private types, private enums and public types and public enums. This was done to keep the SWIG stuff from parsing all sorts of enums and types that weren't needed, and allows us to abstract our API better. llvm-svn: 128239
2011-03-25 05:19:54 +08:00
return eExecutionCompleted;
Moved the code in ClangUserExpression that set up & ran the thread plan with timeouts, and restarting with all threads into a utility function in Process. This required a bunch of renaming. Added a ThreadPlanCallUserExpression that differs from ThreadPlanCallFunction in that it holds onto a shared pointer to its ClangUserExpression so that can't go away before the thread plan is done using it. Fixed the stop message when you hit a breakpoint while running a user expression so it is more obvious what has happened. llvm-svn: 120386
2010-11-30 10:22:11 +08:00
else
Fixed the LLDB build so that we can have private types, private enums and public types and public enums. This was done to keep the SWIG stuff from parsing all sorts of enums and types that weren't needed, and allows us to abstract our API better. llvm-svn: 128239
2011-03-25 05:19:54 +08:00
return eExecutionSetupError;
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
}
else
{
Trivial fix for an error message. llvm-svn: 118697
2010-11-11 03:02:11 +08:00
error_stream.Printf("Expression can't be run; neither DWARF nor a JIT compiled function is present");
Fixed the LLDB build so that we can have private types, private enums and public types and public enums. This was done to keep the SWIG stuff from parsing all sorts of enums and types that weren't needed, and allows us to abstract our API better. llvm-svn: 128239
2011-03-25 05:19:54 +08:00
return eExecutionSetupError;
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
}
}
StreamString &
ClangUserExpression::DwarfOpcodeStream ()
{
if (!m_dwarf_opcodes.get())
m_dwarf_opcodes.reset(new StreamString());
return *m_dwarf_opcodes.get();
}
Moved expression evaluation from CommandObjectExpression into ClangUserExpression::Evaluate () as a public static function so anyone can evaluate an expression. llvm-svn: 115581
2010-10-05 08:31:29 +08:00
Fixed the LLDB build so that we can have private types, private enums and public types and public enums. This was done to keep the SWIG stuff from parsing all sorts of enums and types that weren't needed, and allows us to abstract our API better. llvm-svn: 128239
2011-03-25 05:19:54 +08:00
ExecutionResults
Added a user-settable variable, 'target.expr-prefix', which holds the name of a file whose contents are prefixed to each expression. For example, if the file ~/lldb.prefix.header contains: typedef unsigned short my_type; then you can do this: (lldb) settings set target.expr-prefix '~/lldb.prefix.header' (lldb) expr sizeof(my_type) (unsigned long) $0 = 2 When the variable is changed, the corresponding file is loaded and its contents are fetched into a string that is stored along with the target. This string is then passed to each expression and inserted into it during parsing, like this: typedef unsigned short my_type; void $__lldb_expr(void *$__lldb_arg) { sizeof(my_type); } llvm-svn: 117627
2010-10-29 08:29:03 +08:00
ClangUserExpression::Evaluate (ExecutionContext &exe_ctx,
Added the equivalent of gdb's "unwind-on-signal" to the expression command, and a parameter to control it in ClangUserExpression, and on down to ClangFunction. llvm-svn: 118290
2010-11-06 03:25:48 +08:00
bool discard_on_error,
Added a user-settable variable, 'target.expr-prefix', which holds the name of a file whose contents are prefixed to each expression. For example, if the file ~/lldb.prefix.header contains: typedef unsigned short my_type; then you can do this: (lldb) settings set target.expr-prefix '~/lldb.prefix.header' (lldb) expr sizeof(my_type) (unsigned long) $0 = 2 When the variable is changed, the corresponding file is loaded and its contents are fetched into a string that is stored along with the target. This string is then passed to each expression and inserted into it during parsing, like this: typedef unsigned short my_type; void $__lldb_expr(void *$__lldb_arg) { sizeof(my_type); } llvm-svn: 117627
2010-10-29 08:29:03 +08:00
const char *expr_cstr,
Moved the code in ClangUserExpression that set up & ran the thread plan with timeouts, and restarting with all threads into a utility function in Process. This required a bunch of renaming. Added a ThreadPlanCallUserExpression that differs from ThreadPlanCallFunction in that it holds onto a shared pointer to its ClangUserExpression so that can't go away before the thread plan is done using it. Fixed the stop message when you hit a breakpoint while running a user expression so it is more obvious what has happened. llvm-svn: 120386
2010-11-30 10:22:11 +08:00
const char *expr_prefix,
lldb::ValueObjectSP &result_valobj_sp)
Moved expression evaluation from CommandObjectExpression into ClangUserExpression::Evaluate () as a public static function so anyone can evaluate an expression. llvm-svn: 115581
2010-10-05 08:31:29 +08:00
{
Make a few log messages come out in "log enable lldb step" as well as "log enable lldb expression". llvm-svn: 123784
2011-01-19 06:20:08 +08:00
lldb::LogSP log(lldb_private::GetLogIfAnyCategoriesSet (LIBLLDB_LOG_EXPRESSIONS | LIBLLDB_LOG_STEP));
More logging for use in debugging the interactions between clients of the LLDB API and the expression parser. llvm-svn: 121193
2010-12-08 06:55:01 +08:00
Moved expression evaluation from CommandObjectExpression into ClangUserExpression::Evaluate () as a public static function so anyone can evaluate an expression. llvm-svn: 115581
2010-10-05 08:31:29 +08:00
Error error;
Fixed the LLDB build so that we can have private types, private enums and public types and public enums. This was done to keep the SWIG stuff from parsing all sorts of enums and types that weren't needed, and allows us to abstract our API better. llvm-svn: 128239
2011-03-25 05:19:54 +08:00
ExecutionResults execution_results = eExecutionSetupError;
Added support for loading and unloading shared libraries. This was done by adding support into lldb_private::Process: virtual uint32_t lldb_private::Process::LoadImage (const FileSpec &image_spec, Error &error); virtual Error lldb_private::Process::UnloadImage (uint32_t image_token); There is a default implementation that should work for both linux and MacOSX. This ability has also been exported through the SBProcess API: uint32_t lldb::SBProcess::LoadImage (lldb::SBFileSpec &image_spec, lldb::SBError &error); lldb::SBError lldb::SBProcess::UnloadImage (uint32_t image_token); Modified the DynamicLoader plug-in interface to require it to be able to tell us if it is currently possible to load/unload a shared library: virtual lldb_private::Error DynamicLoader::CanLoadImage () = 0; This way the dynamic loader plug-ins are allows to veto whether we can currently load a shared library since the dynamic loader might know if it is currenlty loading/unloading shared libraries. It might also know about the current host system and know where to check to make sure runtime or malloc locks are currently being held. Modified the expression parser to have ClangUserExpression::Evaluate() be the one that causes the dynamic checkers to be loaded instead of other code that shouldn't have to worry about it. llvm-svn: 118227
2010-11-04 09:54:29 +08:00
if (exe_ctx.process == NULL)
Moved the code in ClangUserExpression that set up & ran the thread plan with timeouts, and restarting with all threads into a utility function in Process. This required a bunch of renaming. Added a ThreadPlanCallUserExpression that differs from ThreadPlanCallFunction in that it holds onto a shared pointer to its ClangUserExpression so that can't go away before the thread plan is done using it. Fixed the stop message when you hit a breakpoint while running a user expression so it is more obvious what has happened. llvm-svn: 120386
2010-11-30 10:22:11 +08:00
{
error.SetErrorString ("Must have a process to evaluate expressions.");
Fix up how the ValueObjects manage their life cycle so that you can hand out a shared pointer to a ValueObject or any of its dependent ValueObjects, and the whole cluster will stay around as long as that shared pointer stays around. llvm-svn: 130035
2011-04-23 07:53:53 +08:00
result_valobj_sp = ValueObjectConstResult::Create (NULL, error);
Fixed the LLDB build so that we can have private types, private enums and public types and public enums. This was done to keep the SWIG stuff from parsing all sorts of enums and types that weren't needed, and allows us to abstract our API better. llvm-svn: 128239
2011-03-25 05:19:54 +08:00
return eExecutionSetupError;
Moved the code in ClangUserExpression that set up & ran the thread plan with timeouts, and restarting with all threads into a utility function in Process. This required a bunch of renaming. Added a ThreadPlanCallUserExpression that differs from ThreadPlanCallFunction in that it holds onto a shared pointer to its ClangUserExpression so that can't go away before the thread plan is done using it. Fixed the stop message when you hit a breakpoint while running a user expression so it is more obvious what has happened. llvm-svn: 120386
2010-11-30 10:22:11 +08:00
}
Added support for loading and unloading shared libraries. This was done by adding support into lldb_private::Process: virtual uint32_t lldb_private::Process::LoadImage (const FileSpec &image_spec, Error &error); virtual Error lldb_private::Process::UnloadImage (uint32_t image_token); There is a default implementation that should work for both linux and MacOSX. This ability has also been exported through the SBProcess API: uint32_t lldb::SBProcess::LoadImage (lldb::SBFileSpec &image_spec, lldb::SBError &error); lldb::SBError lldb::SBProcess::UnloadImage (uint32_t image_token); Modified the DynamicLoader plug-in interface to require it to be able to tell us if it is currently possible to load/unload a shared library: virtual lldb_private::Error DynamicLoader::CanLoadImage () = 0; This way the dynamic loader plug-ins are allows to veto whether we can currently load a shared library since the dynamic loader might know if it is currenlty loading/unloading shared libraries. It might also know about the current host system and know where to check to make sure runtime or malloc locks are currently being held. Modified the expression parser to have ClangUserExpression::Evaluate() be the one that causes the dynamic checkers to be loaded instead of other code that shouldn't have to worry about it. llvm-svn: 118227
2010-11-04 09:54:29 +08:00
if (!exe_ctx.process->GetDynamicCheckers())
{
More logging for use in debugging the interactions between clients of the LLDB API and the expression parser. llvm-svn: 121193
2010-12-08 06:55:01 +08:00
if (log)
log->Printf("== [ClangUserExpression::Evaluate] Installing dynamic checkers ==");
Added support for loading and unloading shared libraries. This was done by adding support into lldb_private::Process: virtual uint32_t lldb_private::Process::LoadImage (const FileSpec &image_spec, Error &error); virtual Error lldb_private::Process::UnloadImage (uint32_t image_token); There is a default implementation that should work for both linux and MacOSX. This ability has also been exported through the SBProcess API: uint32_t lldb::SBProcess::LoadImage (lldb::SBFileSpec &image_spec, lldb::SBError &error); lldb::SBError lldb::SBProcess::UnloadImage (uint32_t image_token); Modified the DynamicLoader plug-in interface to require it to be able to tell us if it is currently possible to load/unload a shared library: virtual lldb_private::Error DynamicLoader::CanLoadImage () = 0; This way the dynamic loader plug-ins are allows to veto whether we can currently load a shared library since the dynamic loader might know if it is currenlty loading/unloading shared libraries. It might also know about the current host system and know where to check to make sure runtime or malloc locks are currently being held. Modified the expression parser to have ClangUserExpression::Evaluate() be the one that causes the dynamic checkers to be loaded instead of other code that shouldn't have to worry about it. llvm-svn: 118227
2010-11-04 09:54:29 +08:00
DynamicCheckerFunctions *dynamic_checkers = new DynamicCheckerFunctions();
StreamString install_errors;
if (!dynamic_checkers->Install(install_errors, exe_ctx))
Fixed error handling when the utility functions that check pointer validity fail to parse. Now lldb does not crash in that case. Also added support for checking Objective-C class validity in the Version 1 runtime as well as Version 2 runtimes with varying levels of available debug support. llvm-svn: 118271
2010-11-05 08:57:06 +08:00
{
if (install_errors.GetString().empty())
error.SetErrorString ("couldn't install checkers, unknown error");
else
error.SetErrorString (install_errors.GetString().c_str());
Fix up how the ValueObjects manage their life cycle so that you can hand out a shared pointer to a ValueObject or any of its dependent ValueObjects, and the whole cluster will stay around as long as that shared pointer stays around. llvm-svn: 130035
2011-04-23 07:53:53 +08:00
result_valobj_sp = ValueObjectConstResult::Create (NULL, error);
Fixed the LLDB build so that we can have private types, private enums and public types and public enums. This was done to keep the SWIG stuff from parsing all sorts of enums and types that weren't needed, and allows us to abstract our API better. llvm-svn: 128239
2011-03-25 05:19:54 +08:00
return eExecutionSetupError;
Fixed error handling when the utility functions that check pointer validity fail to parse. Now lldb does not crash in that case. Also added support for checking Objective-C class validity in the Version 1 runtime as well as Version 2 runtimes with varying levels of available debug support. llvm-svn: 118271
2010-11-05 08:57:06 +08:00
}
Added support for loading and unloading shared libraries. This was done by adding support into lldb_private::Process: virtual uint32_t lldb_private::Process::LoadImage (const FileSpec &image_spec, Error &error); virtual Error lldb_private::Process::UnloadImage (uint32_t image_token); There is a default implementation that should work for both linux and MacOSX. This ability has also been exported through the SBProcess API: uint32_t lldb::SBProcess::LoadImage (lldb::SBFileSpec &image_spec, lldb::SBError &error); lldb::SBError lldb::SBProcess::UnloadImage (uint32_t image_token); Modified the DynamicLoader plug-in interface to require it to be able to tell us if it is currently possible to load/unload a shared library: virtual lldb_private::Error DynamicLoader::CanLoadImage () = 0; This way the dynamic loader plug-ins are allows to veto whether we can currently load a shared library since the dynamic loader might know if it is currenlty loading/unloading shared libraries. It might also know about the current host system and know where to check to make sure runtime or malloc locks are currently being held. Modified the expression parser to have ClangUserExpression::Evaluate() be the one that causes the dynamic checkers to be loaded instead of other code that shouldn't have to worry about it. llvm-svn: 118227
2010-11-04 09:54:29 +08:00
exe_ctx.process->SetDynamicCheckers(dynamic_checkers);
More logging for use in debugging the interactions between clients of the LLDB API and the expression parser. llvm-svn: 121193
2010-12-08 06:55:01 +08:00
if (log)
log->Printf("== [ClangUserExpression::Evaluate] Finished installing dynamic checkers ==");
Added support for loading and unloading shared libraries. This was done by adding support into lldb_private::Process: virtual uint32_t lldb_private::Process::LoadImage (const FileSpec &image_spec, Error &error); virtual Error lldb_private::Process::UnloadImage (uint32_t image_token); There is a default implementation that should work for both linux and MacOSX. This ability has also been exported through the SBProcess API: uint32_t lldb::SBProcess::LoadImage (lldb::SBFileSpec &image_spec, lldb::SBError &error); lldb::SBError lldb::SBProcess::UnloadImage (uint32_t image_token); Modified the DynamicLoader plug-in interface to require it to be able to tell us if it is currently possible to load/unload a shared library: virtual lldb_private::Error DynamicLoader::CanLoadImage () = 0; This way the dynamic loader plug-ins are allows to veto whether we can currently load a shared library since the dynamic loader might know if it is currenlty loading/unloading shared libraries. It might also know about the current host system and know where to check to make sure runtime or malloc locks are currently being held. Modified the expression parser to have ClangUserExpression::Evaluate() be the one that causes the dynamic checkers to be loaded instead of other code that shouldn't have to worry about it. llvm-svn: 118227
2010-11-04 09:54:29 +08:00
}
Moved the code in ClangUserExpression that set up & ran the thread plan with timeouts, and restarting with all threads into a utility function in Process. This required a bunch of renaming. Added a ThreadPlanCallUserExpression that differs from ThreadPlanCallFunction in that it holds onto a shared pointer to its ClangUserExpression so that can't go away before the thread plan is done using it. Fixed the stop message when you hit a breakpoint while running a user expression so it is more obvious what has happened. llvm-svn: 120386
2010-11-30 10:22:11 +08:00
ClangUserExpressionSP user_expression_sp (new ClangUserExpression (expr_cstr, expr_prefix));
Moved expression evaluation from CommandObjectExpression into ClangUserExpression::Evaluate () as a public static function so anyone can evaluate an expression. llvm-svn: 115581
2010-10-05 08:31:29 +08:00
StreamString error_stream;
Made expressions that are just casts of pointer variables be evaluated statically. Also fixed a bug that caused the results of statically-evaluated expressions to be materialized improperly. This bug also removes some duplicate code. llvm-svn: 131042
2011-05-07 09:06:41 +08:00
More logging for use in debugging the interactions between clients of the LLDB API and the expression parser. llvm-svn: 121193
2010-12-08 06:55:01 +08:00
if (log)
log->Printf("== [ClangUserExpression::Evaluate] Parsing expression %s ==", expr_cstr);
Made expressions that are just casts of pointer variables be evaluated statically. Also fixed a bug that caused the results of statically-evaluated expressions to be materialized improperly. This bug also removes some duplicate code. llvm-svn: 131042
2011-05-07 09:06:41 +08:00
if (!user_expression_sp->Parse (error_stream, exe_ctx, TypeFromUser(NULL, NULL), true))
Moved expression evaluation from CommandObjectExpression into ClangUserExpression::Evaluate () as a public static function so anyone can evaluate an expression. llvm-svn: 115581
2010-10-05 08:31:29 +08:00
{
if (error_stream.GetString().empty())
error.SetErrorString ("expression failed to parse, unknown error");
else
error.SetErrorString (error_stream.GetString().c_str());
}
else
{
Modified LLDB expressions to not have to JIT and run code just to see variable values or persistent expression variables. Now if an expression consists of a value that is a child of a variable, or of a persistent variable only, we will create a value object for it and make a ValueObjectConstResult from it to freeze the value (for program variables only, not persistent variables) and avoid running JITed code. For everything else we still parse up and JIT code and run it in the inferior. There was also a lot of clean up in the expression code. I made the ClangExpressionVariables be stored in collections of shared pointers instead of in collections of objects. This will help stop a lot of copy constructors on these large objects and also cleans up the code considerably. The persistent clang expression variables were moved over to the Target to ensure they persist across process executions. Added the ability for lldb_private::Target objects to evaluate expressions. We want to evaluate expressions at the target level in case we aren't running yet, or we have just completed running. We still want to be able to access the persistent expression variables between runs, and also evaluate constant expressions. Added extra logging to the dynamic loader plug-in for MacOSX. ModuleList objects can now dump their contents with the UUID, arch and full paths being logged with appropriate prefix values. Thread hardened the Communication class a bit by making the connection auto_ptr member into a shared pointer member and then making a local copy of the shared pointer in each method that uses it to make sure another thread can't nuke the connection object while it is being used by another thread. Added a new file to the lldb/test/load_unload test that causes the test a.out file to link to the libd.dylib file all the time. This will allow us to test using the DYLD_LIBRARY_PATH environment variable after moving libd.dylib somewhere else. llvm-svn: 121745
2010-12-14 10:59:59 +08:00
lldb::ClangExpressionVariableSP expr_result;
Moved expression evaluation from CommandObjectExpression into ClangUserExpression::Evaluate () as a public static function so anyone can evaluate an expression. llvm-svn: 115581
2010-10-05 08:31:29 +08:00
Made expressions that are just casts of pointer variables be evaluated statically. Also fixed a bug that caused the results of statically-evaluated expressions to be materialized improperly. This bug also removes some duplicate code. llvm-svn: 131042
2011-05-07 09:06:41 +08:00
if (user_expression_sp->m_const_result.get())
Moved expression evaluation from CommandObjectExpression into ClangUserExpression::Evaluate () as a public static function so anyone can evaluate an expression. llvm-svn: 115581
2010-10-05 08:31:29 +08:00
{
More logging for use in debugging the interactions between clients of the LLDB API and the expression parser. llvm-svn: 121193
2010-12-08 06:55:01 +08:00
if (log)
Implemented a feature where the expression parser can avoid running the code in the target if the expression's result is known and the expression has no side effects. Right now this feature is quite conservative in its guess about side effects, and it only computes integer results, but the machinery to make it more sophisticated is there. llvm-svn: 121952
2010-12-16 11:17:46 +08:00
log->Printf("== [ClangUserExpression::Evaluate] Expression evaluated as a constant ==");
More logging for use in debugging the interactions between clients of the LLDB API and the expression parser. llvm-svn: 121193
2010-12-08 06:55:01 +08:00
Made expressions that are just casts of pointer variables be evaluated statically. Also fixed a bug that caused the results of statically-evaluated expressions to be materialized improperly. This bug also removes some duplicate code. llvm-svn: 131042
2011-05-07 09:06:41 +08:00
result_valobj_sp = user_expression_sp->m_const_result->GetValueObject();
Moved expression evaluation from CommandObjectExpression into ClangUserExpression::Evaluate () as a public static function so anyone can evaluate an expression. llvm-svn: 115581
2010-10-05 08:31:29 +08:00
}
Implemented a feature where the expression parser can avoid running the code in the target if the expression's result is known and the expression has no side effects. Right now this feature is quite conservative in its guess about side effects, and it only computes integer results, but the machinery to make it more sophisticated is there. llvm-svn: 121952
2010-12-16 11:17:46 +08:00
else
{
error_stream.GetString().clear();
if (log)
log->Printf("== [ClangUserExpression::Evaluate] Executing expression ==");
execution_results = user_expression_sp->Execute (error_stream,
exe_ctx,
Implemented a major overhaul of the way variables are handled by LLDB. Instead of being materialized into the input structure passed to the expression, variables are left in place and pointers to them are materialzied into the structure. Variables not resident in memory (notably, registers) get temporary memory regions allocated for them. Persistent variables are the most complex part of this, because they are made in various ways and there are different expectations about their lifetime. Persistent variables now have flags indicating their status and what the expectations for longevity are. They can be marked as residing in target memory permanently -- this is the default for result variables from expressions entered on the command line and for explicitly declared persistent variables (but more on that below). Other result variables have their memory freed. Some major improvements resulting from this include being able to properly take the address of variables, better and cleaner support for functions that return references, and cleaner C++ support in general. One problem that remains is the problem of explicitly declared persistent variables; I have not yet implemented the code that makes references to them into indirect references, so currently materialization and dematerialization of these variables is broken. llvm-svn: 123371
2011-01-13 16:53:35 +08:00
discard_on_error,
Implemented a feature where the expression parser can avoid running the code in the target if the expression's result is known and the expression has no side effects. Right now this feature is quite conservative in its guess about side effects, and it only computes integer results, but the machinery to make it more sophisticated is there. llvm-svn: 121952
2010-12-16 11:17:46 +08:00
user_expression_sp,
expr_result);
Fixed the LLDB build so that we can have private types, private enums and public types and public enums. This was done to keep the SWIG stuff from parsing all sorts of enums and types that weren't needed, and allows us to abstract our API better. llvm-svn: 128239
2011-03-25 05:19:54 +08:00
if (execution_results != eExecutionCompleted)
Moved expression evaluation from CommandObjectExpression into ClangUserExpression::Evaluate () as a public static function so anyone can evaluate an expression. llvm-svn: 115581
2010-10-05 08:31:29 +08:00
{
More logging for use in debugging the interactions between clients of the LLDB API and the expression parser. llvm-svn: 121193
2010-12-08 06:55:01 +08:00
if (log)
Implemented a feature where the expression parser can avoid running the code in the target if the expression's result is known and the expression has no side effects. Right now this feature is quite conservative in its guess about side effects, and it only computes integer results, but the machinery to make it more sophisticated is there. llvm-svn: 121952
2010-12-16 11:17:46 +08:00
log->Printf("== [ClangUserExpression::Evaluate] Execution completed abnormally ==");
if (error_stream.GetString().empty())
error.SetErrorString ("expression failed to execute, unknown error");
else
error.SetErrorString (error_stream.GetString().c_str());
Moved expression evaluation from CommandObjectExpression into ClangUserExpression::Evaluate () as a public static function so anyone can evaluate an expression. llvm-svn: 115581
2010-10-05 08:31:29 +08:00
}
Implemented a feature where the expression parser can avoid running the code in the target if the expression's result is known and the expression has no side effects. Right now this feature is quite conservative in its guess about side effects, and it only computes integer results, but the machinery to make it more sophisticated is there. llvm-svn: 121952
2010-12-16 11:17:46 +08:00
else
Moved expression evaluation from CommandObjectExpression into ClangUserExpression::Evaluate () as a public static function so anyone can evaluate an expression. llvm-svn: 115581
2010-10-05 08:31:29 +08:00
{
Implemented a feature where the expression parser can avoid running the code in the target if the expression's result is known and the expression has no side effects. Right now this feature is quite conservative in its guess about side effects, and it only computes integer results, but the machinery to make it more sophisticated is there. llvm-svn: 121952
2010-12-16 11:17:46 +08:00
if (expr_result)
{
result_valobj_sp = expr_result->GetValueObject();
if (log)
Convert ValueObject to explicitly maintain the Execution Context in which they were created, and then use that when they update themselves. That means all the ValueObject evaluate me type functions that used to require a Frame object now do not. I didn't remove the SBValue API's that take this now useless frame, but I added ones that don't require the frame, and marked the SBFrame taking ones as deprecated. llvm-svn: 128593
2011-03-31 08:19:25 +08:00
log->Printf("== [ClangUserExpression::Evaluate] Execution completed normally with result %s ==", result_valobj_sp->GetValueAsCString());
Implemented a feature where the expression parser can avoid running the code in the target if the expression's result is known and the expression has no side effects. Right now this feature is quite conservative in its guess about side effects, and it only computes integer results, but the machinery to make it more sophisticated is there. llvm-svn: 121952
2010-12-16 11:17:46 +08:00
}
else
{
if (log)
log->Printf("== [ClangUserExpression::Evaluate] Execution completed normally with no result ==");
error.SetErrorString ("Expression did not return a result");
}
Moved expression evaluation from CommandObjectExpression into ClangUserExpression::Evaluate () as a public static function so anyone can evaluate an expression. llvm-svn: 115581
2010-10-05 08:31:29 +08:00
}
}
}
Fixed the message that reports that an expression did not return a result. The result is nonexistent (or void), not NULL. llvm-svn: 116855
2010-10-20 04:15:00 +08:00
Added the notion that a value object can be constant by adding: bool ValueObject::GetIsConstant() const; void ValueObject::SetIsConstant(); This will stop anything from being re-evaluated within the value object so that constant result value objects can maintain their frozen values without anything being updated or changed within the value object. Made it so the ValueObjectConstResult can be constructed with an lldb_private::Error object to allow for expression results to have errors. Since ValueObject objects contain error objects, I changed the expression evaluation in ClangUserExpression from static Error ClangUserExpression::Evaluate (ExecutionContext &exe_ctx, const char *expr_cstr, lldb::ValueObjectSP &result_valobj_sp); to: static lldb::ValueObjectSP Evaluate (ExecutionContext &exe_ctx, const char *expr_cstr); Even though expression parsing is borked right now (pending fixes coming from Sean Callanan), I filled in the implementation for: SBValue SBFrame::EvaluateExpression (const char *expr); Modified all expression code to deal with the above changes. llvm-svn: 115589
2010-10-05 11:13:51 +08:00
if (result_valobj_sp.get() == NULL)
Fix up how the ValueObjects manage their life cycle so that you can hand out a shared pointer to a ValueObject or any of its dependent ValueObjects, and the whole cluster will stay around as long as that shared pointer stays around. llvm-svn: 130035
2011-04-23 07:53:53 +08:00
result_valobj_sp = ValueObjectConstResult::Create (NULL, error);
Added the notion that a value object can be constant by adding: bool ValueObject::GetIsConstant() const; void ValueObject::SetIsConstant(); This will stop anything from being re-evaluated within the value object so that constant result value objects can maintain their frozen values without anything being updated or changed within the value object. Made it so the ValueObjectConstResult can be constructed with an lldb_private::Error object to allow for expression results to have errors. Since ValueObject objects contain error objects, I changed the expression evaluation in ClangUserExpression from static Error ClangUserExpression::Evaluate (ExecutionContext &exe_ctx, const char *expr_cstr, lldb::ValueObjectSP &result_valobj_sp); to: static lldb::ValueObjectSP Evaluate (ExecutionContext &exe_ctx, const char *expr_cstr); Even though expression parsing is borked right now (pending fixes coming from Sean Callanan), I filled in the implementation for: SBValue SBFrame::EvaluateExpression (const char *expr); Modified all expression code to deal with the above changes. llvm-svn: 115589
2010-10-05 11:13:51 +08:00
Moved the code in ClangUserExpression that set up & ran the thread plan with timeouts, and restarting with all threads into a utility function in Process. This required a bunch of renaming. Added a ThreadPlanCallUserExpression that differs from ThreadPlanCallFunction in that it holds onto a shared pointer to its ClangUserExpression so that can't go away before the thread plan is done using it. Fixed the stop message when you hit a breakpoint while running a user expression so it is more obvious what has happened. llvm-svn: 120386
2010-11-30 10:22:11 +08:00
return execution_results;
ClangUserExpression ctor should not crash if given a null expr_prefix char*. llvm-svn: 117700
2010-10-30 04:19:44 +08:00
}