[lldb] add stop-at-user-entry option to process launch (#67019)

## Description
This pull request adds a new `stop-at-user-entry` option to LLDB
`process launch` command, allowing users to launch a

[lldb] add stop-at-user-entry option to process launch (#67019)

## Description
This pull request adds a new `stop-at-user-entry` option to LLDB
`process launch` command, allowing users to launch a process and pause
execution at the entry point of the program (for C-based languages,
`main` function).

## Motivation
This option provides a convenient way to begin debugging a program by
launching it and breaking at the desired entry point.

## Changes Made
- Added `stop-at-user-entry` option to `Options.td` and the
corresponding case in `CommandOptionsProcessLaunch.cpp` (short option is
'm')
- Implemented `GetUserEntryPointName` method in the Language plugins
available at the moment.
- Declared the `CreateBreakpointAtUserEntry` method in the Target API.
- Create Shell test for the command
`command-process-launch-user-entry.test`.

## Usage
`process launch --stop-at-user-entry` or `process launch -m` launches
the process and pauses execution at the entry point of the program.

show more ...

[lldb][NFCI] Change return type of Language::GetInstanceVariableName

I don't think this needs to be a ConstString.

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

[lldb] Refactor deduction of the instance variable's name (NFC)

Move responsibility of providing the instance variable name (`this`, `self`) from
`TypeSystem` to `Language`.

`Language` the natural

[lldb] Refactor deduction of the instance variable's name (NFC)

Move responsibility of providing the instance variable name (`this`, `self`) from
`TypeSystem` to `Language`.

`Language` the natural place for this, but also has downstream benefits. Some languages
have multiple `TypeSystem` implementations (ex Swift), and by placing this logic in the
`Language`, redundancy is avoided.

This change relies on the tests from D145348 and D146320.

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

show more ...

[lldb][CPlusPlus] Implement CPlusPlusLanguage::GetFunctionDisplayName

This patch implements the `GetFunctionDisplayName` API which gets
used by the frame-formatting code to decide how to print a
fun

[lldb][CPlusPlus] Implement CPlusPlusLanguage::GetFunctionDisplayName

This patch implements the `GetFunctionDisplayName` API which gets
used by the frame-formatting code to decide how to print a
function name.

Currently this API trivially returns `false`, so we try to parse
the demangled function base-name by hand. We try find the closing
parenthesis by doing a forward scan through the demangled name. However,
for arguments that contain parenthesis (e.g., function pointers)
this would leave garbage in the frame function name.

By re-using the `CPlusPlusLanguage` parser for this we offload the
need to parse function names to a component that knows how to do this
already.

We leave the existing parsing code in `FormatEntity` since it's used
in cases where a language-plugin is not available (and is not
necessarily C++ specific).

**Example**

For following function:
```
int foo(std::function<int(void)> const& func) { return 1; }
```

Before patch:
```
frame #0: 0x000000010000151c a.out`foo(func= Function = bar() )> const&) at sample.cpp:11:49
```

After patch:
```
frame #0: 0x000000010000151c a.out`foo(func= Function = bar() ) at sample.cpp:11:49
```

**Testing**

* Added shell test

show more ...

[lldb][CPlusPlus] Introduce CPlusPlusLanguage::MethodName::GetReturnType

This patch adds a way to extract the return type out
of the `CPlusPlusNameParser`. This will be useful
for cases where we wan

[lldb][CPlusPlus] Introduce CPlusPlusLanguage::MethodName::GetReturnType

This patch adds a way to extract the return type out
of the `CPlusPlusNameParser`. This will be useful
for cases where we want a function's basename *and* the
return type but not the function arguments; this is
currently not possible (the parser either gives us the
full name or just the basename). Since the parser knows
how to handle return types already we should just expose
this to users that need it.

**Testing**

* Added unit-tests

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

show more ...

[lldb][Breakpoint] Fix setting breakpoints on templates by basename

This patch fixes a regression with setting breakpoints on template
functions by name. E.g.,:
```
$ cat main.cpp
template<typename

[lldb][Breakpoint] Fix setting breakpoints on templates by basename

This patch fixes a regression with setting breakpoints on template
functions by name. E.g.,:
```
$ cat main.cpp
template<typename T>
struct Foo {
template<typename U>
void func() {}
};

int main() {
Foo<int> f;
f.func<double>();
}

(lldb) br se -n func
```

This has regressed since `3339000e0bda696c2e29173d15958c0a4978a143`
where we started using the `CPlusPlusNameParser` for getting the
basename of the function symbol and match it exactly against
the name in the breakpoint command. The parser will include template
parameters in the basename, so the exact match will always fail

**Testing**

* Added API tests
* Added unit-tests

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

show more ...

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

Remove ConstString from Language, LanguageRuntime, SystemRuntime and SymbolFile plugin names

[lldb] Return StringRef from PluginInterface::GetPluginName

There is no reason why this function should be returning a ConstString.

While modifying these files, I also fixed several instances where

[lldb] Return StringRef from PluginInterface::GetPluginName

There is no reason why this function should be returning a ConstString.

While modifying these files, I also fixed several instances where
GetPluginName and GetPluginNameStatic were returning different strings.

I am not changing the return type of GetPluginNameStatic in this patch, as that
would necessitate additional changes, and this patch is big enough as it is.

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

show more ...

[lldb] Remove Expression's dependency on CPlusPlusLanguagePlugin

This change accomplishes the following:
- Moves `IRExecutionUnit::FindBestAlternateMangledName` to `Language`.
- Renames `FindBestAlt

[lldb] Remove Expression's dependency on CPlusPlusLanguagePlugin

This change accomplishes the following:
- Moves `IRExecutionUnit::FindBestAlternateMangledName` to `Language`.
- Renames `FindBestAlternateMangledName` to
`FindBestAlternateFunctionMangledName`
- Changes the first parameter of said method from a `ConstString`
representing a demangled name to a `Mangled`.
- Remove the use of CPlusPlusLanguage from Expression

show more ...

[lldb] Refactor and rename CPlusPlusLanguage::FindAlternateFunctionManglings

I have 2 goals with this change:
1. Disambiguate between CPlusPlus::FindAlternateFunctionManglings and
IRExecutionUnit

[lldb] Refactor and rename CPlusPlusLanguage::FindAlternateFunctionManglings

I have 2 goals with this change:
1. Disambiguate between CPlusPlus::FindAlternateFunctionManglings and
IRExecutionUnit::FindBestAlternateMangledName. These are named very
similar things, they try to do very similar things, but their
approaches are different. This change should make it clear that one
is generating possible alternate manglings (through some
heuristics-based approach) and the other is finding alternate
manglings (through searching the SymbolFile for potential matches).
2. Change GenerateAlternateFunctionManglings from a static method in
CPlusPlusLanguage to a virtual method in Language. This will allow us
to remove a direct use of CPlusPlusLanguage in IRExecutionUnit,
further pushing it to be more general. This change doesn't meet this
goal completely but allows for it to happen later.

Though this doesn't remove IRExecutionUnit's dependency on
CPlusPlusLanguage, it does bring us closer to that goal.

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

show more ...

[lldb] Remove PluginInterface::GetPluginVersion

In all these years, we haven't found a use for this function (it has
zero callers). Lets just remove the boilerplate.

Differential Revision: https://

[lldb] Remove PluginInterface::GetPluginVersion

In all these years, we haven't found a use for this function (it has
zero callers). Lets just remove the boilerplate.

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

show more ...

Revert "[lldb] Refactor Module::LookupInfo constructor"

This reverts commit cd2134e42aa7d1168a3ed54e41793b022f961b1f.

Seems like this broke some tests on arm and aarch64 boxes. Will
investigate bef

Revert "[lldb] Refactor Module::LookupInfo constructor"

This reverts commit cd2134e42aa7d1168a3ed54e41793b022f961b1f.

Seems like this broke some tests on arm and aarch64 boxes. Will
investigate before re-landing.

show more ...

[lldb] Refactor Module::LookupInfo constructor

Module::LookupInfo's constructor currently goes over supported languages
trying to figure out the best way to search for a symbol name. This
seems like

[lldb] Refactor Module::LookupInfo constructor

Module::LookupInfo's constructor currently goes over supported languages
trying to figure out the best way to search for a symbol name. This
seems like a great candidate for refactoring. Specifically, this is work
that can be delegated to language plugins.

Once again, the goal here is to further decouple plugins from
non-plugins. The idea is to have each language plugin take a name and
give you back some information about the name from the perspective of
the language. Specifically, each language now implements a
`GetFunctionNameInfo` method which returns an object of type
`Language::FunctionNameInfo`. Right now, it consists of a basename,
a context, and a FunctionNameType. Module::LookupInfo's constructor will
call `GetFunctionNameInfo` with the appropriate language plugin(s) and
then decide what to do with that information. I have attempted to maintain
existing behavior as best as possible.

A nice side effect of this change is that lldbCore no longer links
against the ObjC Language plugin.

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

show more ...

[lldb] Remove CPlusPlusLanguage from Mangled

The only remaining plugin dependency in Mangled is CPlusPlusLanguage which it
uses to extract information from C++ mangled names. The static function
Get

[lldb] Remove CPlusPlusLanguage from Mangled

The only remaining plugin dependency in Mangled is CPlusPlusLanguage which it
uses to extract information from C++ mangled names. The static function
GetDemangledNameWithoutArguments is written specifically for C++, so it
would make sense for this specific functionality to live in a
C++-related plugin. In order to keep this functionality in Mangled
without maintaining this dependency, I added
`Language::GetDemangledFunctionNameWithoutArguments`.

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

show more ...

[lldb] Use C++11 default member initializers

This converts a default constructor's member initializers into C++11
default member initializers. This patch was automatically generated with
clang-tidy

[lldb] Use C++11 default member initializers

This converts a default constructor's member initializers into C++11
default member initializers. This patch was automatically generated with
clang-tidy and the modernize-use-default-member-init check.

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

This is a mass-refactoring patch and this commit will be added to
.git-blame-ignore-revs.

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

show more ...

[lldb][NFC] Use Language plugins in Mangled::GuessLanguage

This removes the direct dependency to the ObjC and C++ plugins.

Reviewed By: bulbazord

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

[lldb][NFC] Use Language plugins in Mangled::GuessLanguage

This removes the direct dependency to the ObjC and C++ plugins.

Reviewed By: bulbazord

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

show more ...

[lldb/DataFormatters] Display null C++ pointers as nullptr

Display null pointer as `nullptr`, `nil` and `NULL` for C++,
Objective-C/Objective-C++ and C respectively. The original motivation
for this

[lldb/DataFormatters] Display null C++ pointers as nullptr

Display null pointer as `nullptr`, `nil` and `NULL` for C++,
Objective-C/Objective-C++ and C respectively. The original motivation
for this patch was to display a null std::string pointer as nullptr
instead of "", but the fix seemed generic enough to be done for all
summary providers.

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

show more ...

[lldb] Update header guards to be consistent and compliant with LLVM (NFC)

LLDB has a few different styles of header guards and they're not very
consistent because things get moved around or copy/pa

[lldb] Update header guards to be consistent and compliant with LLVM (NFC)

LLDB has a few different styles of header guards and they're not very
consistent because things get moved around or copy/pasted. This patch
unifies the header guards across LLDB and converts everything to match
LLVM's style.

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

show more ...

[LLDB] Fix handling for the clang name mangling extension for block invocations

Add support for clangs mangling extension for block invocations.

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

[LLDB] Fix handling for the clang name mangling extension for block invocations

Add support for clangs mangling extension for block invocations.

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

show more ...

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

Pass ConstString by value (NFC)

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, s

Pass ConstString by value (NFC)

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

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

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