Most of our code was including Log.h even though that is not where the
"lldb" log channel is defined (Log.h defines the generic logging
infrastructure). This worked because Log.h included Logging.h, even
though it should.
After the recent refactor, it became impossible the two files include
each other in this direction (the opposite inclusion is needed), so this
patch removes the workaround that was put in place and cleans up all
files to include the right thing. It also renames the file to LLDBLog to
better reflect its purpose.
Both of BreakpointLocation and BreakpointSite were inherited from StoppointLocation. However, the only thing
they shared was hit counting logic. The patch encapsulates those logic into StoppointHitCounter, renames
StoppointLocation to StoppointSite, and stops BreakpointLocation's inheriting from it.
Differential Revision: https://reviews.llvm.org/D84527
Most process plugins (if not all) don't set hardware index for breakpoints. They even
are not able to determine this index.
This patch makes StoppointLocation::IsHardware pure virtual and lets BreakpointSite
override it using more accurate BreakpointSite::Type.
It also adds assertions to be sure that a breakpoint site is hardware when this is required.
Differential Revision: https://reviews.llvm.org/D84257
Summary:
A *.cpp file header in LLDB (and in LLDB) should like this:
```
//===-- TestUtilities.cpp -------------------------------------------------===//
```
However in LLDB most of our source files have arbitrary changes to this format and
these changes are spreading through LLDB as folks usually just use the existing
source files as templates for their new files (most notably the unnecessary
editor language indicator `-*- C++ -*-` is spreading and in every review
someone is pointing out that this is wrong, resulting in people pointing out that this
is done in the same way in other files).
This patch removes most of these inconsistencies including the editor language indicators,
all the different missing/additional '-' characters, files that center the file name, missing
trailing `===//` (mostly caused by clang-format breaking the line).
Reviewers: aprantl, espindola, jfb, shafik, JDevlieghere
Reviewed By: JDevlieghere
Subscribers: dexonsmith, wuzish, emaste, sdardis, nemanjai, kbarton, MaskRay, atanasyan, arphaman, jfb, abidh, jsji, JDevlieghere, usaxena95, lldb-commits
Tags: #lldb
Differential Revision: https://reviews.llvm.org/D73258
Summary:
This commit achieves the following:
- Functions used to return a `TypeSystem *` return an
`llvm::Expected<TypeSystem *>` now. This means that the result of a call
is always checked, forcing clients to move more carefully.
- `TypeSystemMap::GetTypeSystemForLanguage` will either return an Error or a
non-null pointer to a TypeSystem.
Reviewers: JDevlieghere, davide, compnerd
Subscribers: jdoerfert, lldb-commits
Differential Revision: https://reviews.llvm.org/D65122
llvm-svn: 367360
My apologies for the large patch. With the exception of ConstString.h
itself it was entirely produced by sed.
ConstString has exactly one const char * data member, so passing a
ConstString by reference is not any more efficient than copying it by
value. In both cases a single pointer is passed. But passing it by
value makes it harder to accidentally return the address of a local
object.
(This fixes rdar://problem/48640859 for the Apple folks)
Differential Revision: https://reviews.llvm.org/D59030
llvm-svn: 355553
The `ap` suffix is a remnant of lldb's former use of auto pointers,
before they got deprecated. Although all their uses were replaced by
unique pointers, some variables still carried the suffix.
In r353795 I removed another auto_ptr remnant, namely redundant calls to
::get for unique_pointers. Jim justly noted that this is a good
opportunity to clean up the variable names as well.
I went over all the changes to ensure my find-and-replace didn't have
any undesired side-effects. I hope I didn't miss any, but if you end up
at this commit doing a git blame on a weirdly named variable, please
know that the change was unintentional.
llvm-svn: 353912
Summary:
This patch adds support of expression evaluation in a context of some object.
Consider the following example:
```
struct S {
int a = 11;
int b = 12;
};
int main() {
S s;
int a = 1;
int b = 2;
// We have stopped here
return 0;
}
```
This patch allows to do something like that:
```
lldb.frame.FindVariable("s").EvaluateExpression("a + b")
```
and the result will be `33` (not `3`) because fields `a` and `b` of `s` will be
used (not locals `a` and `b`).
This is achieved by replacing of `this` type and object for the expression. This
has some limitations: an expression can be evaluated only for values located in
the debuggee process memory (they must have an address of `eAddressTypeLoad`
type).
Reviewers: teemperor, clayborg, jingham, zturner, labath, davide, spyffe, serge-sans-paille
Reviewed By: jingham
Subscribers: abidh, lldb-commits, leonid.mashinskiy
Tags: #lldb
Differential Revision: https://reviews.llvm.org/D55318
llvm-svn: 353149
to reflect the new license.
We understand that people may be surprised that we're moving the header
entirely to discuss the new license. We checked this carefully with the
Foundation's lawyer and we believe this is the correct approach.
Essentially, all code in the project is now made available by the LLVM
project under our new license, so you will see that the license headers
include that license only. Some of our contributors have contributed
code under our old license, and accordingly, we have retained a copy of
our old license notice in the top-level files in each project and
repository.
llvm-svn: 351636
This patch simplifies boolean expressions acorss LLDB. It was generated
using clang-tidy with the following command:
run-clang-tidy.py -checks='-*,readability-simplify-boolean-expr' -format -fix $PWD
Differential revision: https://reviews.llvm.org/D55584
llvm-svn: 349215
This patch removes the comments grouping header includes. They were
added after running IWYU over the LLDB codebase. However they add little
value, are often outdates and burdensome to maintain.
llvm-svn: 346626
This is intended as a clean up after the big clang-format commit
(r280751), which unfortunately resulted in many of the comment
paragraphs in LLDB being very hard to read.
FYI, the script I used was:
import textwrap
import commands
import os
import sys
import re
tmp = "%s.tmp"%sys.argv[1]
out = open(tmp, "w+")
with open(sys.argv[1], "r") as f:
header = ""
text = ""
comment = re.compile(r'^( *//) ([^ ].*)$')
special = re.compile(r'^((([A-Z]+[: ])|([0-9]+ )).*)|(.*;)$')
for line in f:
match = comment.match(line)
if match and not special.match(match.group(2)):
# skip intentionally short comments.
if not text and len(match.group(2)) < 40:
out.write(line)
continue
if text:
text += " " + match.group(2)
else:
header = match.group(1)
text = match.group(2)
continue
if text:
filled = textwrap.wrap(text, width=(78-len(header)),
break_long_words=False)
for l in filled:
out.write(header+" "+l+'\n')
text = ""
out.write(line)
os.rename(tmp, sys.argv[1])
Differential Revision: https://reviews.llvm.org/D46144
llvm-svn: 331197
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
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
This reverts commit r284795, as it breaks watchpoint handling on arm (and
presumable all architectures that report watchpoint hits without executing the
tripping instruction).
There seems to be something fundamentally wrong with this patch: it uses
process_sp->AddPreResumeAction to re-enable the watchpoint, but the whole point
of the step-over-watchpoint logic (which AFAIK is the only user of this class) is
to disable the watchpoint *after* we resume to do the single step.
I have no idea how to fix this except by reverting the offending patch.
llvm-svn: 284817
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
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
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
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
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
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
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
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
Kazu Hirata