[lldb] Rename Logging.h to LLDBLog.h and clean up includes

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
inf

[lldb] Rename Logging.h to LLDBLog.h and clean up includes

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.

show more ...

[lldb] Convert "LLDB" log channel to the new API

[lldb][NFC] Use C++ versions of the deprecated C standard library headers

The C headers are deprecated so as requested in D102845, this is replacing them
all with their (not deprecated) C++ equivale

[lldb][NFC] Use C++ versions of the deprecated C standard library headers

The C headers are deprecated so as requested in D102845, this is replacing them
all with their (not deprecated) C++ equivalent.

Reviewed By: shafik

Differential Revision: https://reviews.llvm.org/D103084

show more ...

Allow the ThreadPlanStackMap to hold the thread plans for threads
that were not reported by the OS plugin. To facilitate this, move
adding/updating the ThreadPlans for a Thread to the ThreadPlanStac

Allow the ThreadPlanStackMap to hold the thread plans for threads
that were not reported by the OS plugin. To facilitate this, move
adding/updating the ThreadPlans for a Thread to the ThreadPlanStackMap.
Also move dumping thread plans there as well.

Added some tests for "thread plan list" and "thread plan discard" since
I didn't seem to have written any originally.

Differential Revision: https://reviews.llvm.org/D76814

show more ...

Move thread plan stacks into the Process, indexed by TID.

Differential Revision: https://reviews.llvm.org/D75880

[lldb][NFC] Fix all formatting errors in .cpp file headers

Summary:
A *.cpp file header in LLDB (and in LLDB) should like this:
```
//===-- TestUtilities.cpp ----------------------------------------

[lldb][NFC] Fix all formatting errors in .cpp file headers

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

show more ...

[Logging] Replace Log::Printf with LLDB_LOG macro (NFC)

This patch replaces explicit calls to log::Printf with the new LLDB_LOGF
macro. The macro is similar to LLDB_LOG but supports printf-style for

[Logging] Replace Log::Printf with LLDB_LOG macro (NFC)

This patch replaces explicit calls to log::Printf with the new LLDB_LOGF
macro. The macro is similar to LLDB_LOG but supports printf-style format
strings, instead of formatv-style format strings.

So instead of writing:

if (log)
log->Printf("%s\n", str);

You'd write:

LLDB_LOG(log, "%s\n", str);

This change was done mechanically with the command below. I replaced the
spurious if-checks with vim, since I know how to do multi-line
replacements with it.

find . -type f -name '*.cpp' -exec \
sed -i '' -E 's/log->Printf\(/LLDB_LOGF\(log, /g' "{}" +

Differential revision: https://reviews.llvm.org/D65128

llvm-svn: 366936

show more ...

Use the multi-lockable form of std::lock for operator=

For = operators for lists that have mutexes, we were either
just taking the locks sequentially or hand-rolling a trick
to try to avoid lock inv

Use the multi-lockable form of std::lock for operator=

For = operators for lists that have mutexes, we were either
just taking the locks sequentially or hand-rolling a trick
to try to avoid lock inversion. Use the std::lock mechanism
for this instead.

Differential Revision: https://reviews.llvm.org/D59957

llvm-svn: 357276

show more ...

Update the file headers across all of the LLVM projects in the monorepo
to reflect the new license.

We understand that people may be surprised that we're moving the header
entirely to discuss the ne

Update the file headers across all of the LLVM projects in the monorepo
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

show more ...

Remove header grouping comments.

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 outdate

Remove header grouping comments.

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

show more ...

Move RegisterValue,Scalar,State from Core to Utility

These three classes have no external dependencies, but they are used
from various low-level APIs. Moving them down to Utility improves
overall co

Move RegisterValue,Scalar,State from Core to Utility

These three classes have no external dependencies, but they are used
from various low-level APIs. Moving them down to Utility improves
overall code layering (although it still does not break any particular
dependency completely).

The XCode project will need to be updated after this change.

Differential Revision: https://reviews.llvm.org/D49740

llvm-svn: 339127

show more ...

Reflow paragraphs in comments.

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 r

Reflow paragraphs in comments.

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

show more ...

Re-land "Don't assume backing thread shares protocol ID."

When we're dealing with virtual (memory) threads created by the OS
plugins, there's no guarantee that the real thread and the backing
thread

Re-land "Don't assume backing thread shares protocol ID."

When we're dealing with virtual (memory) threads created by the OS
plugins, there's no guarantee that the real thread and the backing
thread share a protocol ID. Instead, we should iterate over the memory
threads to find the virtual thread that is backed by the current real
thread.

Differential revision: https://reviews.llvm.org/D45497

rdar://36485830

The original revision (r329891) was reverted because the associated
tests ran into a deadlock on the Linux bots. That problem was resolved
by r330002.

llvm-svn: 330005

show more ...

Revert "Don't assume backing thread shares protocol ID."

This reverts r329891 because the test case is timing out on linux:
http://lab.llvm.org:8011/builders/lldb-x86_64-ubuntu-14.04-cmake/builds/21

Revert "Don't assume backing thread shares protocol ID."

This reverts r329891 because the test case is timing out on linux:
http://lab.llvm.org:8011/builders/lldb-x86_64-ubuntu-14.04-cmake/builds/21834

llvm-svn: 329897

show more ...

Don't assume backing thread shares protocol ID.

When we're dealing with virtual (memory) threads created by the OS
plugins, there's no guarantee that the real thread and the backing
thread share a p

Don't assume backing thread shares protocol ID.

When we're dealing with virtual (memory) threads created by the OS
plugins, there's no guarantee that the real thread and the backing
thread share a protocol ID. Instead, we should iterate over the memory
threads to find the virtual thread that is backed by the current real
thread.

Differential revision: https://reviews.llvm.org/D45497

rdar://36485830

llvm-svn: 329891

show more ...

Move Log from Core -> Utility.

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-

Move Log from Core -> Utility.

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

show more ...

Break some dependencies in lldbUtility.

Differential Revision: https://reviews.llvm.org/D29359

llvm-svn: 293806

Fixed a crasher that has been borking out heap for a long time.

ThreadList had an assignment operator that didn't lock the "rhs" thread list object. This means a thread list can be mutated while it

Fixed a crasher that has been borking out heap for a long time.

ThreadList had an assignment operator that didn't lock the "rhs" thread list object. This means a thread list can be mutated while it is being copied.

The copy constructor calls the assignment operator as well. So this fixes the unsafe threaded access to ThreadList which we believe is responsible for a lot of crashes.

<rdar://problem/28075793>

llvm-svn: 289100

show more ...

*** This commit represents a complete reformatting of the LLDB source code
*** to conform to clang-format’s LLVM style. This kind of mass change has
*** two obvious implications:

Firstly, merging t

*** This commit represents a complete reformatting of the LLDB source code
*** 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

show more ...

second pass over removal of Mutex and Condition

llvm-svn: 270024

This change introduces a "ExpressionExecutionThread" to the ThreadList.

Turns out that most of the code that runs expressions (e.g. the ObjC runtime grubber) on
behalf of the expression parser was

This change introduces a "ExpressionExecutionThread" to the ThreadList.

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

show more ...

Fix Clang-tidy modernize-use-nullptr and readability-simplify-boolean-expr warnings in some files in source/Target/.

Simplify smart pointers checks in conditions. Other minor fixes.

llvm-svn: 255598

Change the null check to an assert.

llvm-svn: 253092

Add a null check against the ThreadPlan

I'm seeing some cases where the ThreadPlan is null. It could
be a sign of a valid race condition, but at least we shouldn't
crash.

llvm-svn: 253086

Fix TestThreadSpecificBreakpoint.py on Linux after rL252355.

Summary:
On Linux, if a thread-specific conditional breakpoint was hit, it
won't necessarily be the thread that hit the breakpoint itself

Fix TestThreadSpecificBreakpoint.py on Linux after rL252355.

Summary:
On Linux, if a thread-specific conditional breakpoint was hit, it
won't necessarily be the thread that hit the breakpoint itself that
evaluates the conditional expression, so the thread that hit the
breakpoint could still be asked to stop, even though it hasn't been
allowed to run since the previous stop.

Reviewers: sivachandra, jingham

Subscribers: lldb-commits

Differential Revision: http://reviews.llvm.org/D14472

llvm-svn: 252391

show more ...