Summary:
DWARF 5 proposes a reinvented .debug_macro section. This change follows
that spec.
Currently, only GCC produces the .debug_macro section and hence
the added test is annottated with expectedFailureClang.
Reviewers: spyffe, clayborg, tberghammer
Subscribers: lldb-commits
Differential Revision: http://reviews.llvm.org/D15437
llvm-svn: 255729
Summary:
Since this is within the lldb namespace, the compiler tries to
export a symbol for it. Unfortunately, since it is inlined, the
symbol is hidden and this results in a mess of warnings when
building on OS X with cmake.
Moving it to the lldb_private namespace eliminates that problem.
Reviewers: clayborg
Subscribers: emaste, lldb-commits
Differential Revision: http://reviews.llvm.org/D14417
llvm-svn: 252396
callers had to do this by hand and we ended up never actually adding initial arguments and then
reusing them by passing in the struct address separately, so the distinction wasn't needed.
llvm-svn: 252108
The Go interpreter doesn't JIT or use LLVM, so this also
moves all the JIT related code from UserExpression to a new class LLVMUserExpression.
Differential Revision: http://reviews.llvm.org/D13073
Fix merge
llvm-svn: 251820
This makes LLDB launch and create a REPL, specifying no target so that the REPL
can create one for itself. Also added the "--repl-language" option, which
specifies the language to use. Plumbed the relevant arguments and errors
through the REPL creation mechanism.
llvm-svn: 250773
A REPL takes over the command line and typically treats input as source code.
REPLs can also do code completion. The REPL class allows its subclasses to
implement the language-specific functionality without having to know about the
IOHandler-specific internals.
Also added a PluginManager-based way of getting to a REPL given a language and
a target.
Also brought in some utility code and expression options that are useful for
REPLs, such as line offsets for expressions, ANSI terminal coloring of errors,
and a few IOHandler convenience functions.
llvm-svn: 250753
When the target settings are consulted to decide the expression language
is decided in CommandObjectExpression, this doesn't help if you're running
SBFrame::EvaluateExpression(). Moving the logic into UserExpression fixes
this.
Based on patch from scallanan@apple.com
Reviewed by: dawn
Subscribers: lldb-commits
Differential Revision: http://reviews.llvm.org/D13267
llvm-svn: 249624
The concept here is that languages may have different ways of communicating
results. In particular, languages may have different names for their result
variables and in fact may have multiple types of result variables (e.g.,
error results). Materializer was tied to one specific model of result handling.
Instead, now UserExpressions can register their own handlers for the result
variables they inject. This allows language-specific code in Materializer to
be moved into the expression parser plug-in, and it simplifies Materializer.
These delegates are subclasses of PersistentVariableDelegate.
PersistentVariableDelegate can provide the name of the result variable, and is
notified when the result variable is populated. It can also be used to touch
persistent variables if need be, updating language-specific state. The
UserExpression owns the delegate and can decide on its result based on
consulting all of its (potentially multiple) delegates.
The user expression itself now makes the determination of what the final result
of the expression is, rather than relying on the Materializer, and I've added a
virtual function to UserExpression to allow this.
llvm-svn: 249233
The ClangExpressionVariable::CreateVariableInList functions looked cute, but
caused more confusion than they solved. I removed them, and instead made sure
that there are adequate facilities for easily adding newly-constructed
ExpressionVariables to lists.
I also made some of the constructors that are common be generic, so that it's
possible to construct expression variables from generic places (like the ABI and
ValueObject) without having to know the specifics about the class.
llvm-svn: 249095
Also added some target-level search functions so that persistent variables and
symbols can be searched for without hand-iterating across the map of
TypeSystems.
llvm-svn: 249027
the corresponding TypeSystem. This makes sense because what kind of data there
is -- and how it can be looked up -- depends on the language.
Functionality that is common to all type systems is factored out into
PersistentExpressionState.
llvm-svn: 248934
There are still a bunch of dependencies on the plug-in, but this helps to
identify them.
There are also a few more bits we need to move (and abstract, for example the
ClangPersistentVariables).
llvm-svn: 248612
Summary:
This is no longer related to Clang and is just an opaque pointer
to data for a compiler type.
Reviewers: clayborg
Subscribers: lldb-commits
Differential Revision: http://reviews.llvm.org/D13039
llvm-svn: 248288
Summary:
With the recent changes to separate clang from the core structures
of LLDB, many inclusions of clang headers can be removed.
Reviewers: clayborg
Subscribers: lldb-commits
Differential Revision: http://reviews.llvm.org/D12954
llvm-svn: 248004
This cleans up type systems to be more pluggable. Prior to this we had issues:
- Module, SymbolFile, and many others has "ClangASTContext &GetClangASTContext()" functions. All have been switched over to use "TypeSystem *GetTypeSystemForLanguage()"
- Cleaned up any places that were using the GetClangASTContext() functions to use TypeSystem
- Cleaned up Module so that it no longer has dedicated type system member variables:
lldb::ClangASTContextUP m_ast; ///< The Clang AST context for this module.
lldb::GoASTContextUP m_go_ast; ///< The Go AST context for this module.
Now we have a type system map:
typedef std::map<lldb::LanguageType, lldb::TypeSystemSP> TypeSystemMap;
TypeSystemMap m_type_system_map; ///< A map of any type systems associated with this module
- Many places in code were using ClangASTContext static functions to place with CompilerType objects and add modifiers (const, volatile, restrict) and to make typedefs, L and R value references and more. These have been made into CompilerType functions that are abstract:
class CompilerType
{
...
//----------------------------------------------------------------------
// Return a new CompilerType that is a L value reference to this type if
// this type is valid and the type system supports L value references,
// else return an invalid type.
//----------------------------------------------------------------------
CompilerType
GetLValueReferenceType () const;
//----------------------------------------------------------------------
// Return a new CompilerType that is a R value reference to this type if
// this type is valid and the type system supports R value references,
// else return an invalid type.
//----------------------------------------------------------------------
CompilerType
GetRValueReferenceType () const;
//----------------------------------------------------------------------
// Return a new CompilerType adds a const modifier to this type if
// this type is valid and the type system supports const modifiers,
// else return an invalid type.
//----------------------------------------------------------------------
CompilerType
AddConstModifier () const;
//----------------------------------------------------------------------
// Return a new CompilerType adds a volatile modifier to this type if
// this type is valid and the type system supports volatile modifiers,
// else return an invalid type.
//----------------------------------------------------------------------
CompilerType
AddVolatileModifier () const;
//----------------------------------------------------------------------
// Return a new CompilerType adds a restrict modifier to this type if
// this type is valid and the type system supports restrict modifiers,
// else return an invalid type.
//----------------------------------------------------------------------
CompilerType
AddRestrictModifier () const;
//----------------------------------------------------------------------
// Create a typedef to this type using "name" as the name of the typedef
// this type is valid and the type system supports typedefs, else return
// an invalid type.
//----------------------------------------------------------------------
CompilerType
CreateTypedef (const char *name, const CompilerDeclContext &decl_ctx) const;
};
Other changes include:
- Removed "CompilerType TypeSystem::GetIntTypeFromBitSize(...)" and CompilerType TypeSystem::GetFloatTypeFromBitSize(...) and replaced it with "CompilerType TypeSystem::GetBuiltinTypeForEncodingAndBitSize(lldb::Encoding encoding, size_t bit_size);"
- Fixed code in Type.h to not request the full type for a type for no good reason, just request the forward type and let the type expand as needed
llvm-svn: 247953
Summary: Supports the parsing of the "using namespace XXX" and "using XXX::XXX" directives. Added ambiguity errors when it two decls with the same name are encountered (see comments in TestCppNsImport). Fixes using directives being duplicated for anonymous namespaces. Fixes GetDeclForUID for specification DIEs.
Reviewers: sivachandra, chaoren, clayborg
Subscribers: lldb-commits
Differential Revision: http://reviews.llvm.org/D12897
llvm-svn: 247836
Split-dwarf uses a different header format to specify the address range
for the elements of the location lists.
Differential revision: http://reviews.llvm.org/D12880
llvm-svn: 247789
Summary: SymbolFileDWARF now creates VarDecl and BlockDecl and adds them to the Decl tree. Then, in ClangExpressionDeclMap it uses the Decl tree to search for a variable. This fixes lots of variable scoping problems.
Reviewers: sivachandra, chaoren, spyffe, clayborg
Subscribers: tberghammer, jingham, lldb-commits
Differential Revision: http://reviews.llvm.org/D12658
llvm-svn: 247746
Before we had:
ClangFunction
ClangUtilityFunction
ClangUserExpression
and code all over in lldb that explicitly made Clang-based expressions. This patch adds an Expression
base class, and three pure virtual implementations for the Expression kinds:
FunctionCaller
UtilityFunction
UserExpression
You can request one of these expression types from the Target using the Get<ExpressionType>ForLanguage.
The Target will then consult all the registered TypeSystem plugins, and if the type system that matches
the language can make an expression of that kind, it will do so and return it.
Because all of the real expression types need to communicate with their ExpressionParser in a uniform way,
I also added a ExpressionTypeSystemHelper class that expressions generically can vend, and a ClangExpressionHelper
that encapsulates the operations that the ClangExpressionParser needs to perform on the ClangExpression types.
Then each of the Clang* expression kinds constructs the appropriate helper to do what it needs.
The patch also fixes a wart in the UtilityFunction that to use it you had to create a parallel FunctionCaller
to actually call the function made by the UtilityFunction. Now the UtilityFunction can be asked to vend a
FunctionCaller that will run its function. This cleaned up a lot of boiler plate code using UtilityFunctions.
Note, in this patch all the expression types explicitly depend on the LLVM JIT and IR, and all the common
JIT running code is in the FunctionCaller etc base classes. At some point we could also abstract that dependency
but I don't see us adding another back end in the near term, so I'll leave that exercise till it is actually necessary.
llvm-svn: 247720
Summary:
When lldb is processing a location containing DW_OP_piece, the result is being
stored in the 'pieces' variable. The location is popped from the 'stack' variable.
So this check to see that 'stack' is not empty was invalid and caused the pieces
after the first to not get processed.
I am working on an architecture which has 16-bit and 8-bit registers. So this
problem was quite easy to see. But I was able to re-produce this issue on x86
too with long long variable and compiling woth -m32. It resulted in following
location list.
00000014 08048496 080484b5 (DW_OP_reg6 (esi); DW_OP_piece: 4; DW_OP_reg7 (edi); DW_OP_piece: 4)
and lldb was only showing the contents of first register when I evaluated the
variable as it does not process the 2nd piece due to this check.
Reviewers: clayborg, aprantl
Subscribers: lldb-commits
Differential Revision: http://reviews.llvm.org/D12674
llvm-svn: 247124
As part of our overall switch from hand-rolling RTTI to using LLVM-compatible
methods, I've done the same for ExpressionVariable. The main documentation for
how to do this is in TypeSystem.h, so I've simply referred to that.
llvm-svn: 247085
This will keep our code cleaner and it removes the need for intrusive additions to TypeSystem like:
class TypeSystem
{
virtual ClangASTContext *
AsClangASTContext() = 0;
}
As you can now just use the llvm::dyn_cast and other casts.
llvm-svn: 247041
stores information about a variable that different parts of LLDB use, from the
compiler-specific portion that only the expression parser cares about.
http://reviews.llvm.org/D12602
llvm-svn: 246871
* Use the frame's context (instead of just the target's) when evaluating,
so that the language of the frame's CU can be used to select the
compiler and/or compiler options to use when parsing the expression.
This allows for modules built with mixed languages to be parsed in
the context of their frame.
* Add all C and C++ language variants when determining the language options
to set.
* Enable C++ language options when language is C or ObjC as a workaround since
the expression parser uses features of C++ to capture values.
* Enable ObjC language options when language is C++ as a workaround for ObjC
requirements.
* Disable C++11 language options when language is C++03.
* Add test TestMixedLanguages.py to check that the language being used
for evaluation is that of the frame.
* Fix test TestExprOptions.py to check for C++11 instead of C++ since C++ has
to be enabled for C, and remove redundant expr --language test for ObjC.
* Fix TestPersistentPtrUpdate.py to not require C++11 in C.
Reviewed by: clayborg, spyffe, jingham
Subscribers: lldb-commits
Differential Revision: http://reviews.llvm.org/D11102
llvm-svn: 246829
Summary:
This doesn't exist in other LLVM projects any longer and doesn't
do anything.
Reviewers: chaoren, labath
Subscribers: emaste, tberghammer, lldb-commits, danalbert
Differential Revision: http://reviews.llvm.org/D12586
llvm-svn: 246749
This is still something I need to fix, but at least it's not so ugly, and it's
consistent with the other code that does that so we will catch it when we purge
all such code.
llvm-svn: 246738
Clang-specific part, create the ExpressionVariable source/header file and
move ClangExpressionVariable into the Clang expression parser plugin.
It is expected that there are some ugly #include paths... these will be resolved
by either (1) making that code use generic expression variables (once they're
separated appropriately) or (2) moving that code into a plug-in, often
the expression parser plug-in.
llvm-svn: 246737
Siva Chandra