We don't require users to type out the full context of a function, for
symbol name matches. Instead, we extract the incoming path's base
name, look up all the symbols with that base name, and then co

We don't require users to type out the full context of a function, for
symbol name matches. Instead, we extract the incoming path's base
name, look up all the symbols with that base name, and then compare
the rest of the context that the user provided to make sure it
matches. However, we do this comparison using just a strstr. So for
instance:

break set -n foo::bar

will match not only "a::foo::bar" but "notherfoo::bar". The former is
pretty clearly the user's intent, but I don't think the latter is, and
results in breakpoints picking up too many matches.

This change adds a Language::DemangledNameContainsPath API which can
do a language aware match against the path provided. If the language
doesn't provide this we fall back to the strstr (though that's changed
to StringRef::contains in the patch).

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

show more ...

[lldb] Tighten lock in Language::ForEach

It is easy to accidentally introduce a deadlock by having the callback
passed to Language::ForEach also attempt to acquire the same lock. It
is easy enough t

[lldb] Tighten lock in Language::ForEach

It is easy to accidentally introduce a deadlock by having the callback
passed to Language::ForEach also attempt to acquire the same lock. It
is easy enough to disallow the callback from calling anything in
Language directly, but it may happen through a series of other
function/method calls.

The solution I am proposing is to tighten the lock in Language::ForEach
so that it is only held as we gather the currently loaded language
plugins. We store them in a vector and then iterate through them with
the callback so that the callback can't introduce a deadlock.

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

show more ...

[lldb] Replace default bodies of special member functions with = default;

Replace default bodies of special member functions with = default;

$ run-clang-tidy.py -header-filter='lldb' -checks='-*,mo

[lldb] Replace default bodies of special member functions with = default;

Replace default bodies of special member functions with = default;

$ run-clang-tidy.py -header-filter='lldb' -checks='-*,modernize-use-equals-default' -fix ,

https://clang.llvm.org/extra/clang-tidy/checks/modernize-use-equals-default.html

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

show more ...

[lldb] Rename StringRef _lower() method calls to _insensitive()

Rename human-readable name for DW_LANG_Mips_Assembler

The Mips in DW_LANG_Mips_Assembler is a vendor name not an
architecture name and in lack of a proper generic DW_LANG_assembler,
some assemblers

Rename human-readable name for DW_LANG_Mips_Assembler

The Mips in DW_LANG_Mips_Assembler is a vendor name not an
architecture name and in lack of a proper generic DW_LANG_assembler,
some assemblers emit DWARF using this tag. Due to a warning I recently
introduced users will now be greeted with

This version of LLDB has no plugin for the mipsassem language. Inspection of frame variables will be limited.

By renaming this to just "Assembler" this error message will make more sense.

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

rdar://77214764

show more ...

[lldb/DataFormatters] Delete GetStringPrinterEscapingHelper

Summary:
Languages can have different ways of formatting special characters.
E.g. when debugging C++ code a string might look like "\b", b

[lldb/DataFormatters] Delete GetStringPrinterEscapingHelper

Summary:
Languages can have different ways of formatting special characters.
E.g. when debugging C++ code a string might look like "\b", but when
debugging Swift code the same string would look like "\u{8}".

To make this work, plugins override GetStringPrinterEscapingHelper.
However, because there's a large amount of subtly divergent work done in
each override, we end up with large amounts of duplicated code. And all
the memory smashers fixed in one copy of the logic (see D73860) don't
get fixed in the others.

IMO the GetStringPrinterEscapingHelper is overly general and hard to
use. I propose deleting it and replacing it with an EscapeStyle enum,
which can be set as needed by each plugin.

A fix for some swift-lldb memory smashers falls out fairly naturally
from this deletion (https://github.com/apple/llvm-project/pull/1046). As
the swift logic becomes really tiny, I propose moving it upstream as
part of this change. I've added unit tests to cover it.

rdar://61419673

Reviewers: JDevlieghere, davide

Subscribers: mgorny, lldb-commits

Tags: #lldb

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

show more ...

[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 ...

Remove TypeValidators (NFC in terms of the testsuite)

This is a half-implemented feature that as far as we can tell was
never used by anything since its original inclusion in 2014. This
patch remove

Remove TypeValidators (NFC in terms of the testsuite)

This is a half-implemented feature that as far as we can tell was
never used by anything since its original inclusion in 2014. This
patch removes it to make remaining the code easier to understand.

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

show more ...

Extend FindTypes with CompilerContext to allow filtering by language.

This patch is also motivated by the Swift branch and is effectively NFC for the single-TypeSystem llvm.org branch.

In multi-lan

Extend FindTypes with CompilerContext to allow filtering by language.

This patch is also motivated by the Swift branch and is effectively NFC for the single-TypeSystem llvm.org branch.

In multi-language projects it is extremely common to have, e.g., a
Clang type and a similarly-named rendition of that same type in
another language. When searching for a type It is much cheaper to pass
a set of supported languages to the SymbolFile than having it
materialize every result and then rejecting the materialized types
that have the wrong language.

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

<rdar://problem/54471165>

This reapplies r369690 with a previously missing constructor for LanguageSet.

llvm-svn: 369710

show more ...

Revert Extend FindTypes with CompilerContext to allow filtering by language.

This reverts r369690 (git commit aa3a564efa6b5fff2129f81a4041069a0233168f)

llvm-svn: 369702

Extend FindTypes with CompilerContext to allow filtering by language.

This patch is also motivated by the Swift branch and is effectively NFC for the single-TypeSystem llvm.org branch.

In multi-lan

Extend FindTypes with CompilerContext to allow filtering by language.

This patch is also motivated by the Swift branch and is effectively NFC for the single-TypeSystem llvm.org branch.

In multi-language projects it is extremely common to have, e.g., a
Clang type and a similarly-named rendition of that same type in
another language. When searching for a type It is much cheaper to pass
a set of supported languages to the SymbolFile than having it
materialize every result and then rejecting the materialized types
that have the wrong language.

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

<rdar://problem/54471165>

llvm-svn: 369690

show more ...

[Target] Introduce Process::GetLanguageRuntimes

Summary:
Currently there's not really a good way to iterate over the language runtimes a
process has. This is sometimes desirable (as seen in my chang

[Target] Introduce Process::GetLanguageRuntimes

Summary:
Currently there's not really a good way to iterate over the language runtimes a
process has. This is sometimes desirable (as seen in my change to Thread).
Additionally, there's not really a good reason to iterate over every available
language, but rather only over languages for which we have a plugin loaded.

Reviewers: JDevlieghere, davide, jingham

Subscribers: lldb-commits

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

llvm-svn: 361999

show more ...

Factor out switch statement into a helper function (NFC)

This addresses post-commit review feedback for https://reviews.llvm.org/D62015.

llvm-svn: 360930

[NFC] Remove ASCII lines from comments

A lot of comments in LLDB are surrounded by an ASCII line to delimit the
begging and end of the comment.

Its use is not really consistent across the code base

[NFC] Remove ASCII lines from comments

A lot of comments in LLDB are surrounded by an ASCII line to delimit the
begging and end of the comment.

Its use is not really consistent across the code base, sometimes the
lines are longer, sometimes they are shorter and sometimes they are
omitted. Furthermore, it looks kind of weird with the 80 column limit,
where the comment actually extends past the line, but not by much.
Furthermore, when /// is used for Doxygen comments, it looks
particularly odd. And when // is used, it incorrectly gives the
impression that it's actually a Doxygen comment.

I assume these lines were added to improve distinguishing between
comments and code. However, given that todays editors and IDEs do a
great job at highlighting comments, I think it's worth to drop this for
the sake of consistency. The alternative is fixing all the
inconsistencies, which would create a lot more churn.

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

llvm-svn: 358135

show more ...

Remove redundant ::get() for smart pointer. (NFC)

This commit removes redundant calls to smart pointer’s ::get() method.

https://clang.llvm.org/extra/clang-tidy/checks/readability-redundant-smartpt

Remove redundant ::get() for smart pointer. (NFC)

This commit removes redundant calls to smart pointer’s ::get() method.

https://clang.llvm.org/extra/clang-tidy/checks/readability-redundant-smartptr-get.html

llvm-svn: 353795

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 ...

[SymbolFile] Remove SymbolContext parameter from FindTypes.

This parameter was only ever used with the Module set, and
since a SymbolFile is tied to a module, the parameter turns
out to be entirely

[SymbolFile] Remove SymbolContext parameter from FindTypes.

This parameter was only ever used with the Module set, and
since a SymbolFile is tied to a module, the parameter turns
out to be entirely unnecessary. Furthermore, it doesn't make
a lot of sense to ask a caller to ask SymbolFile which is tied
to Module X to find types for Module Y, but that possibility
was open with the previous interface. By removing this
parameter from the API, it makes it harder to use incorrectly
as well as easier for an implementor to understand what it
needs to do.

llvm-svn: 351133

show more ...

[LLDB] Added syntax highlighting support

Summary:
This patch adds syntax highlighting support to LLDB. When enabled (and lldb is allowed
to use colors), printed source code is annotated with the ANS

[LLDB] Added syntax highlighting support

Summary:
This patch adds syntax highlighting support to LLDB. When enabled (and lldb is allowed
to use colors), printed source code is annotated with the ANSI color escape sequences.

So far we have only one highlighter which is based on Clang and is responsible for all
languages that are supported by Clang. It essentially just runs the raw lexer over the input
and then surrounds the specific tokens with the configured escape sequences.

Reviewers: zturner, davide

Reviewed By: davide

Subscribers: labath, teemperor, llvm-commits, mgorny, lldb-commits

Tags: #lldb

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

llvm-svn: 338662

show more ...

Rename Error -> Status.

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 h

Rename Error -> Status.

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

show more ...

Switch std::call_once to llvm::call_once

Summary:
The std::call_once implementation in libstdc++ has problems on few systems: NetBSD, OpenBSD and Linux PPC. LLVM ships with a homegrown implementatio

Switch std::call_once to llvm::call_once

Summary:
The std::call_once implementation in libstdc++ has problems on few systems: NetBSD, OpenBSD and Linux PPC. LLVM ships with a homegrown implementation llvm::call_once to help on these platforms.

This change is required in the NetBSD LLDB port. std::call_once with libstdc++ results with crashing the debugger.

Sponsored by <The NetBSD Foundation>

Reviewers: labath, joerg, emaste, mehdi_amini, clayborg

Reviewed By: labath, clayborg

Subscribers: #lldb

Tags: #lldb

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

llvm-svn: 294202

show more ...

Move classes from Core -> Utility.

This moves the following classes from Core -> Utility.

ConstString
Error
RegularExpression
Stream
StreamString

The goal here is to get lldbUtility into a state w

Move classes from Core -> Utility.

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

show more ...

Implement a general type scavenger that can dig types from debug info + a filtering mechanism to accept/reject results thusly obtained

Implement the C++ type lookup support in terms of this general

Implement a general type scavenger that can dig types from debug info + a filtering mechanism to accept/reject results thusly obtained

Implement the C++ type lookup support in terms of this general scavenger

The idea is that we may want other languages to do debug info based search (exclusively, or as an add-on to runtime/module based searching) and it makes sense to avoid duplicating this functionality

llvm-svn: 285727

show more ...

Update OptionGroup::SetValue to take StringRef.

Then deal with all the fallout.

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

llvm-svn: 282265

Convert many functions to use StringRefs.

Where possible, remove the const char* version. To keep the
risk and impact here minimal, I've only done the simplest
functions.

In the process, I found a

Convert many functions to use StringRefs.

Where possible, remove the const char* version. To keep the
risk and impact here minimal, I've only done the simplest
functions.

In the process, I found a few opportunities for adding some
unit tests, so I added those as well.

Tested on Windows, Linux, and OSX.

llvm-svn: 281799

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 ...