| Age | Commit message (Collapse) | Author |
|---|
|
continue in commands.
Also, watchpoint commands, like breakpoint commands, need to run in async mode.
This was causing intermittent failures in TestWatchpointCommandPython.py, which is now solid.
llvm-svn: 284795
|
|
Plumb unique_ptrs<> all the way through the baton interface.
NFC, this is a minor improvement to remove the possibility of an
accidental pointer ownership issue.
Reviewed By: jingham
Differential Revision: https://reviews.llvm.org/D24495
llvm-svn: 281360
|
|
*** 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
|
|
ignore feature for architectures with watchpoint_exceptions_received=before
Reviewers: jingham.
Subscribers: clayborg, jaydeep, bhushan, sagar, nitesh.jain, lldb-commits.
Differential Revision: http://reviews.llvm.org/D13296
llvm-svn: 251905
|
|
UserExpression. This
isn't used in this commit but will be in a future commit.
llvm-svn: 251887
|
|
minor fixes.
llvm-svn: 251716
|
|
Reviewers: clayborg, zturner.
Subscribers: jaydeep, bhushan, sagar, nitesh.jain, brucem,lldb-commits.
Differential Revision: http://reviews.llvm.org/D13202
llvm-svn: 249838
|
|
that lldb currently vends.
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
|
|
This is more preparation for multiple different kinds of types from different compilers (clang, Pascal, Go, RenderScript, Swift, etc).
llvm-svn: 244689
|
|
A long time ago we start with clang types that were created by the symbol files and there were many functions in lldb_private::ClangASTContext that helped. Later we create ClangASTType which contains a clang::ASTContext and an opauque QualType, but we didn't switch over to fully using it. There were a lot of places where we would pass around a raw clang_type_t and also pass along a clang::ASTContext separately. This left room for error.
This checkin change all type code over to use ClangASTType everywhere and I cleaned up the interfaces quite a bit. Any code that was in ClangASTContext that was type related, was moved over into ClangASTType. All code that used these types was switched over to use all of the new goodness.
llvm-svn: 186130
|
|
Major fixed to allow reading files that are over 4GB. The main problems were that the DataExtractor was using 32 bit offsets as a data cursor, and since we mmap all of our object files we could run into cases where if we had a very large core file that was over 4GB, we were running into the 4GB boundary.
So I defined a new "lldb::offset_t" which should be used for all file offsets.
After making this change, I enabled warnings for data loss and for enexpected implicit conversions temporarily and found a ton of things that I fixed.
Any functions that take an index internally, should use "size_t" for any indexes and also should return "size_t" for any sizes of collections.
llvm-svn: 173463
|
|
<rdar://problem/11597849>
llvm-svn: 170400
|
|
- use macros from inttypes.h for format strings instead of OS-specific types
Patch from Matt Kopec!
llvm-svn: 168945
|
|
llvm-svn: 166502
|
|
with, and use
it to print the old and new values.
Temporarily disable the "out of scope" checking since it didn't work correctly, and was
not what people generally expected watchpoints to be doing.
llvm-svn: 166472
|
|
itself to be disabled!
Previously we put a WatchpointSentry object within StopInfo.cpp to disable-and-then-enable the watchpoint itself
while we are performing the actions associated with the triggered watchpoint, which can cause the user-initiated
watchpoint disabling action to be negated.
Add a test case to verify that a watchpoint can be disabled during the callbacks.
llvm-svn: 162483
|
|
http://llvm.org/viewvc/llvm-project?rev=162322&view=rev.
llvm-svn: 162328
|
|
Watchpoint conditions were hitting watchpoint, smashing LLDB's stack.
Make sure watchpoint is properly disabled and subsequently enabled while performing watchpoint actions.
llvm-svn: 162322
|
|
llvm-svn: 161903
|
|
to evaluate the variable expression,
do not take the sanpshot and forget about the stop info. It is possible that the variable expression has gone
out of scope, we'll revise the hit count due to the false alarms.
llvm-svn: 161892
|
|
Change the test case, too.
llvm-svn: 161806
|
|
Record the snapshot of our watched value when the watchpoint is set or hit.
And report the old/new values when watchpoint is triggered. Add some test scenarios.
llvm-svn: 161785
|
|
Add 'watchpoint command add/delete/list' to lldb, plus two .py test files.
llvm-svn: 161638
|
|
replace them with
includes of ClangUserExpression that were being errantly dragged in through same.
llvm-svn: 155970
|
|
Now Each newly created target has its Watchpoint IDs as 1, 2, 3 ...
llvm-svn: 151435
|
|
braces.
llvm-svn: 151292
|
|
"frame var -w".
Also add test cases for watching a variable as well as a location expressed as an expression.
o TestMyFirstWatchpoint.py:
Modified to test "watchpoint set -w write global".
o TestWatchLocationWithWatchSet.py:
Added to test "watchpoint set -w write -x 1 g_char_ptr + 7" where a contrived example program
with several threads is supposed to only access the array index within the range [0..6], but
there's some misbehaving thread writing past the range.
rdar://problem/10701761
llvm-svn: 149280
|
|
accessing member field.
llvm-svn: 148756
|
|
member fields.
llvm-svn: 148743
|
|
parser has hitherto been an implementation waiting
for a use. I have now tied the '-o' option for
the expression command -- which indicates that the
result is an Objective-C object and needs to be
printed -- to the ExpressionParser, which
communicates the desired type to Clang.
Now, if the result of an expression is determined
by an Objective-C method call for which there is
no type information, that result is implicitly
cast to id if and only if the -o option is passed
to the expression command. (Otherwise if there
is no explicit cast Clang will issue an error.
This behavior is identical to what happened before
r146756.)
Also added a testcase for -o enabled and disabled.
llvm-svn: 147099
|
|
llvm-svn: 145735
|
|
which will in the future allow expressions to be
compiled as C, C++, and Objective-C instead of the
current default Objective-C++. This feature requires
some additional support from Clang -- specifically, it
requires reference types in the parser regardless of
language -- so it is not yet exposed to the user.
llvm-svn: 144042
|
|
watchpoint modify -c 'global==5'
modifies the last created watchpoint so that the condition expression
is evaluated at the stop point to decide whether we should proceed with
the stopping.
Also add SBWatchpont::SetCondition(const char *condition) to set condition
programmatically.
Test cases to come later.
llvm-svn: 142227
|
|
llvm-svn: 141979
|
|
creating
a watchpoint for either the variable encapsulated by SBValue (Watch) or the pointee
encapsulated by SBValue (WatchPointee).
Removed SBFrame::WatchValue() and SBFrame::WatchLocation() API as a result of that.
Modified the watchpoint related test suite to reflect the change.
Plus replacing WatchpointLocation with Watchpoint throughout the code base.
There are still cleanups to be dome. This patch passes the whole test suite.
Check it in so that we aggressively catch regressions.
llvm-svn: 141925
|
