This setting can be enabled like this at the target level:
(lldb) settings set target.experimental.use-modern-type-lookup true
This causes several new behaviors in the Clang expression parser:
- It completely disables use of ClangASTImporter. None are created
at all, and all users of it are now conditionalized on its
presence.
- It instead constructs a per-expression ExternalASTMerger, which
exists inside Clang and contains much of the type completion
logic that hitherto lived in ExternalASTSource,
ClangExpressionDeclMap, and ClangASTImporter.
- The expression parser uses this Merger as a backend for copying
and completing types.
- It also constructs a persistent ExternalASTMerger which is
connected to the Target's persistent AST context.
This is a major chunk of LLDB functionality moved into Clang. It
can be tested in two ways:
1. For an individual debug session, enable the setting before
running a target.
2. For the testsuite, change the option to be default-true. This
is done in Target.cpp's g_experimental_properties. The
testsuite is not yet clean with this, so I have not committed
that switch.
I have filed a Bugzilla for extending the testsuite to allow
custom settings for all tests:
https://bugs.llvm.org/show_bug.cgi?id=34771
I have also filed a Bugzilla for fixing the remaining testsuite
failures with this setting enabled:
https://bugs.llvm.org/show_bug.cgi?id=34772
llvm-svn: 314458
The IR dynamic checks are self-contained functions whose job is to
- verify that pointers referenced in an expression are valid at runtime; and
- verify that selectors sent to Objective-C objects by an expression are
actually supported by that object.
These dynamic checks forward-declare all the functions they use and should not
require any external debug information. The way they ensure this is by marking
all the names they use with a dollar sign ($). The expression parser recognizes
such symbols and perform no lookups for them.
This patch fixes three issues surrounding the use of the dollar sign:
- to fix a MIPS issue, the name of the pointer checker was changed from
starting with $ to starting with _$, but this was not properly ignored; and
- the Objective-C object checker used a temporary variable that did not start
with $.
- the Objective-C object checker used an externally-defined struct (struct
objc_selector) but didn't need to.
The patch also implements some cleanup in the area:
- it reformats the string containing the Objective-C object checker,
which was mangled horribly when the code was transformed to a uniform width
of 80 columns, and
- it factors out the logic for ignoring global $-symbols into common code
shared between ClangASTSource and ClangExpressionDeclMap.
Differential Revision: https://reviews.llvm.org/D38153
llvm-svn: 314225
Summary:
The classes have no dependencies, and they are used both by lldb and
lldb-server, so it makes sense for them to live in the lowest layers.
Reviewers: zturner, jingham
Subscribers: emaste, mgorny, lldb-commits
Differential Revision: https://reviews.llvm.org/D34746
llvm-svn: 306682
The Timer destructor would grab a global mutex in order to update
execution time. Add a class to define a category once, statically; the
class adds itself to an atomic singly linked list, and thus subsequent
updates only need to use an atomic rather than grab a lock and perform a
hashtable lookup.
Differential Revision: https://reviews.llvm.org/D32823
Patch by Scott Smith <scott.smith@purestorage.com>.
llvm-svn: 303058
This renames the LLDB error class to Status, as discussed
on the lldb-dev mailing list.
A change of this magnitude cannot easily be done without
find and replace, but that has potential to catch unwanted
occurrences of common strings such as "Error". Every effort
was made to find all the obvious things such as the word "Error"
appearing in a string, etc, but it's possible there are still
some lingering occurences left around. Hopefully nothing too
serious.
llvm-svn: 302872
I've filed a bug covering better unit testing of our runtime metadata reader, which will allow this to be testable..
<rdar://problem/31793264>
llvm-svn: 301461
Change the get shared class info function to only
dump its results to the inferior stdout when the
log is verbose. This matches the lldb side of the
same process, which only logs what it found if the
log is on verbose.
llvm-svn: 299451
was formatted into a string inside an assert() expression.
Which is elided when lldb is built with asserts disabled;
the result is that all expressions will fail when debugging
programs using the objective-c v1 runtime.
<rdar://problem/30353271>
llvm-svn: 298694
All references to Host and Core have been removed, so this
class can now safely be lowered into Utility.
Differential Revision: https://reviews.llvm.org/D30559
llvm-svn: 296909
Summary:
Per discussion in D28616, having two ways two request logging (log
enable lldb XXX verbose && log enable -v lldb XXX) is confusing. This
removes the first option and standardizes all code to use the second
one.
I've added a LLDB_LOGV macro as a shorthand for if(log &&
log->GetVerbose()) and switched most of the affected log statements to
use that (I've only left a couple of cases that were doing complex
computations in an if(log) block).
Reviewers: jingham, zturner
Subscribers: lldb-commits
Differential Revision: https://reviews.llvm.org/D29510
llvm-svn: 294113
This moves the following classes from Core -> Utility.
ConstString
Error
RegularExpression
Stream
StreamString
The goal here is to get lldbUtility into a state where it has
no dependendencies except on itself and LLVM, so it can be the
starting point at which to start untangling LLDB's dependencies.
These are all low level and very widely used classes, and
previously lldbUtility had dependencies up to lldbCore in order
to use these classes. So moving then down to lldbUtility makes
sense from both the short term and long term perspective in
solving this problem.
Differential Revision: https://reviews.llvm.org/D29427
llvm-svn: 293941
We don't parse ObjC v1 types from the runtime metadata like we do for ObjC v2, but doing so by creating empty types was ruining the i386 v1 debugging experience.
<rdar://problem/24093343>
llvm-svn: 289233
This is a large API change that removes the two functions from
StreamString that return a std::string& and a const std::string&,
and instead provide one function which returns a StringRef.
Direct access to the underlying buffer violates the concept of
a "stream" which is intended to provide forward only access,
and makes porting to llvm::raw_ostream more difficult in the
future.
Differential Revision: https://reviews.llvm.org/D26698
llvm-svn: 287152
This change is very mechanical. All it does is change the
signature of `Options::GetDefinitions()` and `OptionGroup::
GetDefinitions()` to return an `ArrayRef<OptionDefinition>`
instead of a `const OptionDefinition *`. In the case of the
former, it deletes the sentinel entry from every table, and
in the case of the latter, it removes the `GetNumDefinitions()`
method from the interface. These are no longer necessary as
`ArrayRef` carries its own length.
In the former case, iteration was done by using a sentinel
entry, so there was no knowledge of length. Because of this
the individual option tables were allowed to be defined below
the corresponding class (after all, only a pointer was needed).
Now, however, the length must be known at compile time to
construct the `ArrayRef`, and as a result it is necessary to
move every option table before its corresponding class. This
results in this CL looking very big, but in terms of substance
there is not much here.
Differential revision: https://reviews.llvm.org/D24834
llvm-svn: 282188
This updates getters and setters to use StringRef instead of
const char *. I tested the build on Linux, Windows, and OSX
and saw no build or test failures. I cannot test any BSD
or Android variants, however I expect the required changes
to be minimal or non-existant.
llvm-svn: 282079
The switch coveres all possible values. If a new one is added in the
future the compiler will start warning, providing a notification that
the switch needs updating.
llvm-svn: 280933
*** to conform to clang-format’s LLVM style. This kind of mass change has
*** two obvious implications:
Firstly, merging this particular commit into a downstream fork may be a huge
effort. Alternatively, it may be worth merging all changes up to this commit,
performing the same reformatting operation locally, and then discarding the
merge for this particular commit. The commands used to accomplish this
reformatting were as follows (with current working directory as the root of
the repository):
find . \( -iname "*.c" -or -iname "*.cpp" -or -iname "*.h" -or -iname "*.mm" \) -exec clang-format -i {} +
find . -iname "*.py" -exec autopep8 --in-place --aggressive --aggressive {} + ;
The version of clang-format used was 3.9.0, and autopep8 was 1.2.4.
Secondly, “blame” style tools will generally point to this commit instead of
a meaningful prior commit. There are alternatives available that will attempt
to look through this change and find the appropriate prior commit. YMMV.
llvm-svn: 280751
This is useful because that knowledge will in turn allow no-code-running formatting of boolean NSNumbers; but that's a commit that will have to wait Monday..
llvm-svn: 279353
Options used to store a reference to the CommandInterpreter instance
in the base Options class. This made it impossible to parse options
independent of a CommandInterpreter.
This change removes the reference from the base class. Instead, it
modifies the options-parsing-related methods to take an
ExecutionContext pointer, which the options may inspect if they need
to do so.
Closes https://reviews.llvm.org/D23416
Reviewers: clayborg, jingham
llvm-svn: 278440
It's always hard to remember when to include this file, and
when you do include it it's hard to remember what preprocessor
check it needs to be behind, and then you further have to remember
whether it's windows.h or win32.h which you need to include.
This patch changes the name to PosixApi.h, which is more appropriately
named, and makes it independent of any preprocessor setting.
There's still the issue of people not knowing when to include this,
because there's not a well-defined set of things it exposes other
than "whatever is missing on Windows", but at least this should
make it less painful to fix when problems arise.
This patch depends on LLVM revision r278170.
llvm-svn: 278177
Only ever warn about missing ObjC runtime class data if one either can't run the expressions to obtain such data, or the total count of classes is below a threshold that makes things sound really suspicious
Fixes rdar://27438500
llvm-svn: 276220
review it for consistency, accuracy, and clarity. These changes attempt to
address all of the above while keeping the text relatively terse.
<rdar://problem/24868841>
llvm-svn: 275485
Summary:
The function FunctionCaller::WriteFunctionArguments returns false on
errors, so they should check for the false return value.
Change by Walter Erquinigo <a20012251@gmail.com>
Reviewers: jingham, clayborg
Subscribers: lldb-commits
Differential Revision: http://reviews.llvm.org/D22278
llvm-svn: 275287
This is a pretty straightforward first pass over removing a number of uses of
Mutex in favor of std::mutex or std::recursive_mutex. The problem is that there
are interfaces which take Mutex::Locker & to lock internal locks. This patch
cleans up most of the easy cases. The only non-trivial change is in
CommandObjectTarget.cpp where a Mutex::Locker was split into two.
llvm-svn: 269877
"Allow LanguageRuntimes to return an error if they fail in the course of dynamic type discovery
This is not meant to report that a value doesn't have a dynamic type - it is only meant as a mechanism to propagate actual type discovery issues (e.g. malformed type metadata for languages that have such a notion)
This information is used by ValueObjectDynamic to set its own m_error, which is a fairly sharp and heavyweight tool to begin with
For the time being, this is an architectural improvement but a practical no-op as no existing runtimes are actually setting errors"
I need to think about what I want to do in this space more carefully - this attempt might be too heavy of a hammer for the nail I am trying to fix, and I don't want to leave it in while I ponder
llvm-svn: 268686
This is not meant to report that a value doesn't have a dynamic type - it is only meant as a mechanism to propagate actual type discovery issues (e.g. malformed type metadata for languages that have such a notion)
This information is used by ValueObjectDynamic to set its own m_error, which is a fairly sharp and heavyweight tool to begin with
For the time being, this is an architectural improvement but a practical no-op as no existing runtimes are actually setting errors
llvm-svn: 268591
This allows these functions to be re-used by a forthcoming
PDBASTParser. The functions in question are CanCompleteType,
CompleteType, and CanImport. Conceptually, these functions belong
on ClangASTImporter anyway, and previously they were just ping
ponging around through a few levels of indirection to end up there
as well, so this patch actually makes the code somewhat simpler.
A few methods were moved to a new file called ClangUtil, so that
they can be shared between ClangASTImporter and ClangASTContext
without creating a circular dependency between those two cpp
files.
Differential Revision: http://reviews.llvm.org/D18381
llvm-svn: 264685
a way for compilation to take a "thread to use for compilation". If it isn't set then the
compilation will use the currently selected thread. This should help keep function execution
to the one thread intended.
llvm-svn: 263972
We want to do a better job presenting errors that occur when evaluating
expressions. Key to this effort is getting away from a model where all
errors are spat out onto a stream where the client has to take or leave
all of them.
To this end, this patch adds a new class, DiagnosticManager, which
contains errors produced by the compiler or by LLDB as an expression
is created. The DiagnosticManager can dump itself to a log as well as
to a string. Clients will (in the future) be able to filter out the
errors they're interested in by ID or present subsets of these errors
to the user.
This patch is not intended to change the *users* of errors - only to
thread DiagnosticManagers to all the places where streams are used. I
also attempt to standardize our use of errors a bit, removing trailing
newlines and making clients omit 'error:', 'warning:' etc. and instead
pass the Severity flag.
The patch is testsuite-neutral, with modifications to one part of the
MI tests because it relied on "error: error:" being erroneously
printed. This patch fixes the MI variable handling and the testcase.
<rdar://problem/22864976>
llvm-svn: 263859
Turns out that most of the code that runs expressions (e.g. the ObjC runtime grubber) on
behalf of the expression parser was using the currently selected thread. But sometimes,
e.g. when we are evaluating breakpoint conditions/commands, we don't select the thread
we're running on, we instead set the context for the interpreter, and explicitly pass
that to other callers. That wasn't getting communicated to these utility expressions, so
they would run on some other thread instead, and that could cause a variety of subtle and
hard to reproduce problems.
I also went through the commands and cleaned up the use of GetSelectedThread. All those
uses should have been trying the thread in the m_exe_ctx belonging to the command object
first. It would actually have been pretty hard to get misbehavior in these cases, but for
correctness sake it is good to make this usage consistent.
<rdar://problem/24978569>
llvm-svn: 263326
That way you can set offset breakpoints that will move as the function they are
contained in moves (which address breakpoints can't do...)
I don't align the new address to instruction boundaries yet, so you have to get
this right yourself for now.
<rdar://problem/13365575>
llvm-svn: 263049
This code was doing the right thing for the iOS simulator, but not other simulator platforms
Fix it by making the warning not happen for all platforms whose name ends in "-simulator"
Since this code lives in AppleObjCRuntimeV2.cpp, this already only applies to Apple platforms by definition, so I am not too worried about conflicts with other vendors
llvm-svn: 261165
process in the incoming value be non-null, but Value Objects created off the target
don't necessarily have a process. In that case, having the targets the same is good
enough.
<rdar://problem/24097805>
llvm-svn: 257234
Summary:
This is a resubmission of r252179, but correctly ignores the source
files for other platforms.
Reviewers: granata.enrico, tberghammer, zturner, jingham
Subscribers: lldb-commits
Differential Revision: http://reviews.llvm.org/D14389
llvm-svn: 252205
Summary:
This short-circuits the GetObjCVersion function to avoid iterating through target modules on
non-apple targets. This function is called on every Process::IsDynamicValue call, so this
overhead is not negligible.
Reviewers: clayborg, jingham
Subscribers: lldb-commits
Differential Revision: http://reviews.llvm.org/D13948
llvm-svn: 251004
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
This is meant to cover cases such as the obvious
Base *base = new Derived();
where GetDynamicTypeAndAddress(base) would return the type "Derived", not "Derived *"
llvm-svn: 248315
For C++ and ObjC, dynamic values are always (at least somewhat) pointer-like in nature, so a ValueType of scalar is actually good enough that it could originally be hardcoded as the right choice
Other languages, might have broader notions of things that are dynamic (e.g. a language where a value type can be dynamic). In those cases, it might actually be the case that a dynamic value is a pointer-to the data, or even a host address if dynamic expression results entirely in host space are being talked about
This patch enables the language runtime to make that decision, and makes ValueObjectDynamicValue comply with it
llvm-svn: 247957
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:
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
Summary:
When calling find_first_of and find_last_of on a single character,
we can instead just call find / rfind and make our intent more
clear.
Reviewers: clayborg
Subscribers: lldb-commits
Differential Revision: http://reviews.llvm.org/D12518
llvm-svn: 246609
Create a new "lldb_private::CompilerDeclContext" class that will replace all direct uses of "clang::DeclContext" when used in compiler agnostic code, yet still allow for conversion to clang::DeclContext subclasses by clang specific code. This completes the abstraction of type parsing by removing all "clang::" references from the SymbolFileDWARF. The new "lldb_private::CompilerDeclContext" class abstracts decl contexts found in compiler type systems so they can be used in internal API calls. The TypeSystem is required to support CompilerDeclContexts with new pure virtual functions that start with "DeclContext" in the member function names. Converted all code that used lldb_private::ClangNamespaceDecl over to use the new CompilerDeclContext class and removed the ClangNamespaceDecl.cpp and ClangNamespaceDecl.h files.
Removed direct use of clang APIs from SBType and now use the abstract type systems to correctly explore types.
Bulk renames for things that used to return a ClangASTType which is now CompilerType:
"Type::GetClangFullType()" to "Type::GetFullCompilerType()"
"Type::GetClangLayoutType()" to "Type::GetLayoutCompilerType()"
"Type::GetClangForwardType()" to "Type::GetForwardCompilerType()"
"Value::GetClangType()" to "Value::GetCompilerType()"
"Value::SetClangType (const CompilerType &)" to "Value::SetCompilerType (const CompilerType &)"
"ValueObject::GetClangType ()" to "ValueObject::GetCompilerType()"
many more renames that are similar.
llvm-svn: 245905
This is more preparation for multiple different kinds of types from different compilers (clang, Pascal, Go, RenderScript, Swift, etc).
llvm-svn: 244689
This is the work done by Ryan Brown from http://reviews.llvm.org/D8712 that makes a TypeSystem class and abstracts types to be able to use a type system.
All tests pass on MacOSX and passed on linux the last time this was submitted.
llvm-svn: 244679
Summary:
This replaces (void)x; usages where they x was subsequently
involved in an assertion with this macro to make the
intent more clear.
Reviewers: clayborg
Subscribers: lldb-commits
Differential Revision: http://reviews.llvm.org/D11451
llvm-svn: 243074
Target and breakpoints options were added:
breakpoint set --language lang --name func
settings set target.language pascal
These specify the Language to use when interpreting the breakpoint's
expression (note: currently only implemented for breakpoints on
identifiers). If the breakpoint language is not set, the target.language
setting is used.
This support is required by Pascal, for example, to set breakpoint at 'ns.foo'
for function 'foo' in namespace 'ns'.
Tests on the language were also added to Module::PrepareForFunctionNameLookup
for efficiency.
Reviewed by: clayborg
Subscribers: jingham, lldb-commits
Differential Revision: http://reviews.llvm.org/D11119
llvm-svn: 242844
Summary: This aligns the library names used by the Makefile build to be the same as those create by the CMake build to make switching between the two easier. The only major difficulty was lldbHost which was one library in the CMake system and several in the Makefile system. Most of the other changes are trivial renames.
Reviewers: labath
Subscribers: emaste, tberghammer, lldb-commits
Differential Revision: http://reviews.llvm.org/D11154
llvm-svn: 242196
A few extras were fixed
- Symbol::GetAddress() now returns an Address object, not a reference. There were places where people were accessing the address of a symbol when the symbol's value wasn't an address symbol. On MacOSX, undefined symbols have a value zero and some places where using the symbol's address and getting an absolute address of zero (since an Address object with no section and an m_offset whose value isn't LLDB_INVALID_ADDRESS is considered an absolute address). So fixing this required some changes to make sure people were getting what they expected.
- Since some places want to access the address as a reference, I added a few new functions to symbol:
Address &Symbol::GetAddressRef();
const Address &Symbol::GetAddressRef() const;
Linux test suite passes just fine now.
<rdar://problem/21494354>
llvm-svn: 240702
The expression parser mode allows UnknownAnyTy to make it all the way through, but that is bad for ivars because it means type layout fails horribly (as in, clang crashes)
This patch fixes the issue by using the "variables view mode", which masks UnknownAnyTy as empty-type, and pointer-to UnknownAnyTy as void*
This, in turn, allows LLDB to properly reconstruct ivars of IMP type in ObjC type - as per accompanying test case
Fixes rdar://21471326
llvm-svn: 240677
Since interaction with the python interpreter is moving towards
being more isolated, we won't be able to include this header from
normal files anymore, all includes of it should be localized to
the python library which will live under source/bindings/API/Python
after a future patch.
None of the files that were including this header actually depended
on it anyway, so it was just a dead include in every single instance.
llvm-svn: 238581
This works for Python commands defined via a class (implement get_flags on your class) and C++ plugin commands (which can call SBCommand::GetFlags()/SetFlags())
Flags allow features such as not letting the command run if there's no target, or if the process is not stopped, ...
Commands could always check for these things themselves, but having these accessible via flags makes custom commands more consistent with built-in ones
llvm-svn: 238286
Sean Callanan