[lldb] Move ValueObject into its own library (NFC) (#113393)

ValueObject is part of lldbCore for historical reasons, but conceptually
it deserves to be its own library. This does introduce a (link-

[lldb] Move ValueObject into its own library (NFC) (#113393)

ValueObject is part of lldbCore for historical reasons, but conceptually
it deserves to be its own library. This does introduce a (link-time) circular
dependency between lldbCore and lldbValueObject, which is unfortunate
but probably unavoidable because so many things in LLDB rely on
ValueObject. We already have cycles and these libraries are never built
as dylibs so while this doesn't improve the situation, it also doesn't
make things worse.

The header includes were updated with the following command:

```
find . -type f -exec sed -i.bak "s%include \"lldb/Core/ValueObject%include \"lldb/ValueObject/ValueObject%" '{}' \;
```

show more ...

[lldb] Change SymbolContext::GetAddressRangeFromHereToEndLine to return Expected (NFC) (#110718)

Signed-off-by: AbdAlRahman Gad <abdobngad@gmail.com>
Co-authored-by: Adrian Prantl <adrian.prantl@gm

[lldb] Change SymbolContext::GetAddressRangeFromHereToEndLine to return Expected (NFC) (#110718)

Signed-off-by: AbdAlRahman Gad <abdobngad@gmail.com>
Co-authored-by: Adrian Prantl <adrian.prantl@gmail.com>

show more ...

[lldb] Unify implementation of CommandReturnObject::SetError(NFC) (#110707)

This is a cleanup that moves the API towards value semantics.

[lldb] Turn lldb_private::Status into a value type. (#106163)

This patch removes all of the Set.* methods from Status.

This cleanup is part of a series of patches that make it harder use the
ant

[lldb] Turn lldb_private::Status into a value type. (#106163)

This patch removes all of the Set.* methods from Status.

This cleanup is part of a series of patches that make it harder use the
anti-pattern of keeping a long-lives Status object around and updating
it while dropping any errors it contains on the floor.

This patch is largely NFC, the more interesting next steps this enables
is to:
1. remove Status.Clear()
2. assert that Status::operator=() never overwrites an error
3. remove Status::operator=()

Note that step (2) will bring 90% of the benefits for users, and step
(3) will dramatically clean up the error handling code in various
places. In the end my goal is to convert all APIs that are of the form

` ResultTy DoFoo(Status& error)
`
to

` llvm::Expected<ResultTy> DoFoo()
`
How to read this patch?

The interesting changes are in Status.h and Status.cpp, all other
changes are mostly

` perl -pi -e 's/\.SetErrorString/ = Status::FromErrorString/g' $(git
grep -l SetErrorString lldb/source)
`
plus the occasional manual cleanup.

show more ...

Revert "Revert "[lldb] Extend frame recognizers to hide frames from backtraces (#104523)""

This reverts commit 547917aebd1e79a8929b53f0ddf3b5185ee4df74.

Revert "[lldb] Extend frame recognizers to hide frames from backtraces (#104523)"

This reverts commit f01f80ce6ca7640bb0e267b84b1ed0e89b57e2d9.

This commit introduces an msan violation. See the dis

Revert "[lldb] Extend frame recognizers to hide frames from backtraces (#104523)"

This reverts commit f01f80ce6ca7640bb0e267b84b1ed0e89b57e2d9.

This commit introduces an msan violation. See the discussion on https://github.com/llvm/llvm-project/pull/104523.

show more ...

[lldb] Extend frame recognizers to hide frames from backtraces (#104523)

Compilers and language runtimes often use helper functions that are
fundamentally uninteresting when debugging anything but

[lldb] Extend frame recognizers to hide frames from backtraces (#104523)

Compilers and language runtimes often use helper functions that are
fundamentally uninteresting when debugging anything but the
compiler/runtime itself. This patch introduces a user-extensible
mechanism that allows for these frames to be hidden from backtraces and
automatically skipped over when navigating the stack with `up` and
`down`.

This does not affect the numbering of frames, so `f <N>` will still
provide access to the hidden frames. The `bt` output will also print a
hint that frames have been hidden.

My primary motivation for this feature is to hide thunks in the Swift
programming language, but I'm including an example recognizer for
`std::function::operator()` that I wished for myself many times while
debugging LLDB.

rdar://126629381


Example output. (Yes, my proof-of-concept recognizer could hide even
more frames if we had a method that returned the function name without
the return type or I used something that isn't based off regex, but it's
really only meant as an example).

before:
```
(lldb) thread backtrace --filtered=false
* thread #1, queue = 'com.apple.main-thread', stop reason = breakpoint 1.1
* frame #0: 0x0000000100001f04 a.out`foo(x=1, y=1) at main.cpp:4:10
frame #1: 0x0000000100003a00 a.out`decltype(std::declval<int (*&)(int, int)>()(std::declval<int>(), std::declval<int>())) std::__1::__invoke[abi:se200000]<int (*&)(int, int), int, int>(__f=0x000000016fdff280, __args=0x000000016fdff224, __args=0x000000016fdff220) at invoke.h:149:25
frame #2: 0x000000010000399c a.out`int std::__1::__invoke_void_return_wrapper<int, false>::__call[abi:se200000]<int (*&)(int, int), int, int>(__args=0x000000016fdff280, __args=0x000000016fdff224, __args=0x000000016fdff220) at invoke.h:216:12
frame #3: 0x0000000100003968 a.out`std::__1::__function::__alloc_func<int (*)(int, int), std::__1::allocator<int (*)(int, int)>, int (int, int)>::operator()[abi:se200000](this=0x000000016fdff280, __arg=0x000000016fdff224, __arg=0x000000016fdff220) at function.h:171:12
frame #4: 0x00000001000026bc a.out`std::__1::__function::__func<int (*)(int, int), std::__1::allocator<int (*)(int, int)>, int (int, int)>::operator()(this=0x000000016fdff278, __arg=0x000000016fdff224, __arg=0x000000016fdff220) at function.h:313:10
frame #5: 0x0000000100003c38 a.out`std::__1::__function::__value_func<int (int, int)>::operator()[abi:se200000](this=0x000000016fdff278, __args=0x000000016fdff224, __args=0x000000016fdff220) const at function.h:430:12
frame #6: 0x0000000100002038 a.out`std::__1::function<int (int, int)>::operator()(this= Function = foo(int, int) , __arg=1, __arg=1) const at function.h:989:10
frame #7: 0x0000000100001f64 a.out`main(argc=1, argv=0x000000016fdff4f8) at main.cpp:9:10
frame #8: 0x0000000183cdf154 dyld`start + 2476
(lldb)
```

after

```
(lldb) bt
* thread #1, queue = 'com.apple.main-thread', stop reason = breakpoint 1.1
* frame #0: 0x0000000100001f04 a.out`foo(x=1, y=1) at main.cpp:4:10
frame #1: 0x0000000100003a00 a.out`decltype(std::declval<int (*&)(int, int)>()(std::declval<int>(), std::declval<int>())) std::__1::__invoke[abi:se200000]<int (*&)(int, int), int, int>(__f=0x000000016fdff280, __args=0x000000016fdff224, __args=0x000000016fdff220) at invoke.h:149:25
frame #2: 0x000000010000399c a.out`int std::__1::__invoke_void_return_wrapper<int, false>::__call[abi:se200000]<int (*&)(int, int), int, int>(__args=0x000000016fdff280, __args=0x000000016fdff224, __args=0x000000016fdff220) at invoke.h:216:12
frame #6: 0x0000000100002038 a.out`std::__1::function<int (int, int)>::operator()(this= Function = foo(int, int) , __arg=1, __arg=1) const at function.h:989:10
frame #7: 0x0000000100001f64 a.out`main(argc=1, argv=0x000000016fdff4f8) at main.cpp:9:10
frame #8: 0x0000000183cdf154 dyld`start + 2476
Note: Some frames were hidden by frame recognizers
```

show more ...

[lldb] Delete StepScope enum whose values are ignored. (#101981)

StepScope enum is a type whose values are passed around, but they are
ultimately ignored.

---------

Co-authored-by: Matej Koší

[lldb] Delete StepScope enum whose values are ignored. (#101981)

StepScope enum is a type whose values are passed around, but they are
ultimately ignored.

---------

Co-authored-by: Matej Košík <matej.kosik@codasip.com>

show more ...

[lldb] Unify the way we get the Target in CommandObject (#101208)

Currently, CommandObjects are obtaining a target in a variety of ways.
Often the command incorrectly operates on the selected targe

[lldb] Unify the way we get the Target in CommandObject (#101208)

Currently, CommandObjects are obtaining a target in a variety of ways.
Often the command incorrectly operates on the selected target. As an
example, when a breakpoint command is running, the current target is
passed into the command but the target that hit the breakpoint is not
the selected target. In other places we use the CommandObject's
execution context, which is frozen during the execution of the command,
and comes with its own limitations. Finally, we often want to fall back
to the dummy target if no real target is available.

Instead of having to guess how to get the target, this patch introduces
one helper function in CommandObject to get the most relevant target. In
order of priority, that's the target from the command object's execution
context, from the interpreter's execution context, the selected target
or the dummy target.

rdar://110846511

show more ...

Add the ability for Script based commands to specify their "repeat command" (#94823)

Among other things, returning an empty string as the repeat command
disables auto-repeat, which can be useful fo

Add the ability for Script based commands to specify their "repeat command" (#94823)

Among other things, returning an empty string as the repeat command
disables auto-repeat, which can be useful for state-changing commands.

There's one remaining refinement to this setup, which is that for parsed
script commands, it should be possible to change an option value, or add
a new option value that wasn't originally specified, then ask lldb "make
this back into a command string". That would make doing fancy things
with repeat commands easier.

That capability isn't present in the lldb_private side either, however.
So that's for a next iteration.

I haven't added this to the docs on adding commands yet. I wanted to
make sure this was an acceptable approach before I spend the time to do
that.

show more ...

Convert ValueObject::Dump() to return llvm::Error() (NFCish)

This change by itself has no measurable effect on the LLDB
testsuite. I'm making it in preparation for threading through more
errors in t

Convert ValueObject::Dump() to return llvm::Error() (NFCish)

This change by itself has no measurable effect on the LLDB
testsuite. I'm making it in preparation for threading through more
errors in the Swift language plugin.

show more ...

[lldb] Fix declaration of thread argument in CommandObjectThreadStepWithTypeAndScope (#95146)

`thread step-in` (and other step commands) take a `<thread-index>`, not a `<thread-id>`.

[lldb] Add the word "backtrace" to bt help string (#92618)

We noticed that `apropos backtrace` did not return the `bt` alias. This change adds the
word "backtrace" to the help for `bt`. It also upd

[lldb] Add the word "backtrace" to bt help string (#92618)

We noticed that `apropos backtrace` did not return the `bt` alias. This change adds the
word "backtrace" to the help for `bt`. It also updates `thread backtrace` to keep the
language used roughly in sync.

show more ...

[lldb] Use operator==(StringRef, StringRef) instead of StringRef::equals (NFC) (#92476)

Note that StringRef::equals has been deprecated in favor of
operator==(StringRef, StringRef).

[lldb] Reland: Store SupportFile in FileEntry (NFC) (#85892)

This is another step towards supporting DWARF5 checksums and inline
source code in LLDB. This is a reland of #85468 but without the
fun

[lldb] Reland: Store SupportFile in FileEntry (NFC) (#85892)

This is another step towards supporting DWARF5 checksums and inline
source code in LLDB. This is a reland of #85468 but without the
functional change of storing the support file from the line table (yet).

show more ...

Revert "[lldb] Store SupportFile in FileEntry (NFC)" (#85885)

Reverts llvm/llvm-project#85468 because @slackito reports this broke
stepping in one of their tests [1] and this patch was meant to be

Revert "[lldb] Store SupportFile in FileEntry (NFC)" (#85885)

Reverts llvm/llvm-project#85468 because @slackito reports this broke
stepping in one of their tests [1] and this patch was meant to be NFC.

[1]
https://github.com/llvm/llvm-project/commit/d5a277d309e92b1d3e493da6036cffdf815105b1#commitcomment-139991120

show more ...

[lldb] Store SupportFile in FileEntry (NFC) (#85468)

This is another step towards supporting DWARF5 checksums and inline
source code in LLDB.

[lldb] Fix -Wformat after #83602

[lldb] Fix `thread backtrace --count` (#83602)

The help output for `thread backtrace` specifies that you can pass -1 to
`--count` to display all the frames.

```
-c <count> ( --count <count> )

[lldb] Fix `thread backtrace --count` (#83602)

The help output for `thread backtrace` specifies that you can pass -1 to
`--count` to display all the frames.

```
-c <count> ( --count <count> )
How many frames to display (-1 for all)
```

However, that doesn't work:

```
(lldb) thread backtrace --count -1
error: invalid integer value for option 'c'
```

The problem is that we store the option value as an unsigned and the
code to parse the string correctly rejects it. There's two ways to fix
this:

1. Make `m_count` a signed value so that it accepts negative values and
appease the parser. The function that prints the frames takes an
unsigned so a negative value will just become a really large positive
value, which is what the current implementation relies on.
2. Keep `m_count` unsigned and instead use 0 the magic value to show all
frames. I don't really see a point in not showing any frames at all,
plus that's already broken (`error: error displaying backtrace for
thread: "0x0001"`).

This patch implements (2) and at the same time improve the error
reporting so that we print the invalid value when we cannot parse it.

rdar://123881767

show more ...

Start to clean up the process of defining command arguments. (#83097)

Partly, there's just a lot of unnecessary boiler plate. It's also
possible to define combinations of arguments that make no sen

Start to clean up the process of defining command arguments. (#83097)

Partly, there's just a lot of unnecessary boiler plate. It's also
possible to define combinations of arguments that make no sense (e.g.
eArgRepeatPlus followed by eArgRepeatPlain...) but these are never
checked since we just push_back directly into the argument definitions.

This commit is step 1 of this cleanup - do the obvious stuff. In it, all
the simple homogenous argument lists and the breakpoint/watchpoint
ID/Range types, are set with common functions. This is an NFC change, it
just centralizes boiler plate. There's no checking yet because you can't
get a single argument wrong.

The end goal is that all argument definition goes through functions and
m_arguments is hidden so that you can't define inconsistent argument
sets.

show more ...

Add the RegisterCompleter to eArgTypeRegisterName in g_argument_table (#82428)

This is a follow-on to:

https://github.com/llvm/llvm-project/pull/82085

The completer for register names was miss

Add the RegisterCompleter to eArgTypeRegisterName in g_argument_table (#82428)

This is a follow-on to:

https://github.com/llvm/llvm-project/pull/82085

The completer for register names was missing from the argument table. I
somehow missed that the only register completer test was x86_64, so that
test broke.

I added the completer in to the right slot in the argument table, and
added a small completions test that just uses the alias register names.
If we end up having a platform that doesn't define register names, we'll
have to skip this test there, but it should add a sniff test for
register completion that will run most everywhere.

show more ...

Revert "Centralize the handling of completion for simple argument lists. (#82085)"

This reverts commit 21631494b068d9364b8dc8f18e59adee9131a0a5.

Reverted because of greendragon failure:

**********

Revert "Centralize the handling of completion for simple argument lists. (#82085)"

This reverts commit 21631494b068d9364b8dc8f18e59adee9131a0a5.

Reverted because of greendragon failure:

******************** TEST 'lldb-api :: functionalities/completion/TestCompletion.py' FAILED ********************
Script:

show more ...

Centralize the handling of completion for simple argument lists. (#82085)

Most commands were adding argument completion handling by themselves,
resulting in a lot of unnecessary boilerplate. In man

Centralize the handling of completion for simple argument lists. (#82085)

Most commands were adding argument completion handling by themselves,
resulting in a lot of unnecessary boilerplate. In many cases, this could
be done generically given the argument definition and the entries in the
g_argument_table.

I'm going to address this in a couple passes. In this first pass, I
added handling of commands that have only one argument list, with one
argument type, either single or repeated, and changed all the commands
that are of this sort (and don't have other bits of business in their
completers.)

I also added some missing connections between arg types and completions
to the table, and added a RemoteFilename and RemotePath to use in places
where we were using the Remote completers. Those arguments used to say
they were "files" but they were in fact remote files.

I also added a module arg type to use where we were using the module
completer. In that case, we should call the argument module.

show more ...

[lldb] Use StringRef::{starts,ends}_with (NFC)

This patch replaces uses of StringRef::{starts,ends}with with
StringRef::{starts,ends}_with for consistency with
std::{string,string_view}::{starts,end

[lldb] Use StringRef::{starts,ends}_with (NFC)

This patch replaces uses of StringRef::{starts,ends}with with
StringRef::{starts,ends}_with for consistency with
std::{string,string_view}::{starts,ends}_with in C++20.

I'm planning to deprecate and eventually remove
StringRef::{starts,ends}with.

show more ...

Add option to pass thread ID to thread select command (#73596)

We'd like a way to select the current thread by its thread ID (rather
than its internal LLDB thread index).

This PR adds a `-t` opt

Add option to pass thread ID to thread select command (#73596)

We'd like a way to select the current thread by its thread ID (rather
than its internal LLDB thread index).

This PR adds a `-t` option (`--thread_id` long option) that tells the
`thread select` command to interpret the `<thread-index>` argument as a
thread ID.

Here's an example of it working:
```
michristensen@devbig356 llvm/llvm-project (thread-select-tid) » ../Debug/bin/lldb ~/scratch/cpp/threading/a.out
(lldb) target create "/home/michristensen/scratch/cpp/threading/a.out"
Current executable set to '/home/michristensen/scratch/cpp/threading/a.out' (x86_64).
(lldb) b 18
Breakpoint 1: where = a.out`main + 80 at main.cpp:18:12, address = 0x0000000000000850
(lldb) run
Process 215715 launched: '/home/michristensen/scratch/cpp/threading/a.out' (x86_64)
This is a thread, i=1
This is a thread, i=2
This is a thread, i=3
This is a thread, i=4
This is a thread, i=5
Process 215715 stopped
* thread #1, name = 'a.out', stop reason = breakpoint 1.1
frame #0: 0x0000555555400850 a.out`main at main.cpp:18:12
15 for (int i = 0; i < 5; i++) {
16 pthread_create(&thread_ids[i], NULL, foo, NULL);
17 }
-> 18 for (int i = 0; i < 5; i++) {
19 pthread_join(thread_ids[i], NULL);
20 }
21 return 0;
(lldb) thread select 2
* thread #2, name = 'a.out'
frame #0: 0x00007ffff68f9918 libc.so.6`__nanosleep + 72
libc.so.6`__nanosleep:
-> 0x7ffff68f9918 <+72>: cmpq $-0x1000, %rax ; imm = 0xF000
0x7ffff68f991e <+78>: ja 0x7ffff68f9952 ; <+130>
0x7ffff68f9920 <+80>: movl %edx, %edi
0x7ffff68f9922 <+82>: movl %eax, 0xc(%rsp)
(lldb) thread info
thread #2: tid = 216047, 0x00007ffff68f9918 libc.so.6`__nanosleep + 72, name = 'a.out'

(lldb) thread list
Process 215715 stopped
thread #1: tid = 215715, 0x0000555555400850 a.out`main at main.cpp:18:12, name = 'a.out', stop reason = breakpoint 1.1
* thread #2: tid = 216047, 0x00007ffff68f9918 libc.so.6`__nanosleep + 72, name = 'a.out'
thread #3: tid = 216048, 0x00007ffff68f9918 libc.so.6`__nanosleep + 72, name = 'a.out'
thread #4: tid = 216049, 0x00007ffff68f9918 libc.so.6`__nanosleep + 72, name = 'a.out'
thread #5: tid = 216050, 0x00007ffff68f9918 libc.so.6`__nanosleep + 72, name = 'a.out'
thread #6: tid = 216051, 0x00007ffff68f9918 libc.so.6`__nanosleep + 72, name = 'a.out'
(lldb) thread select 215715
error: invalid thread #215715.
(lldb) thread select -t 215715
* thread #1, name = 'a.out', stop reason = breakpoint 1.1
frame #0: 0x0000555555400850 a.out`main at main.cpp:18:12
15 for (int i = 0; i < 5; i++) {
16 pthread_create(&thread_ids[i], NULL, foo, NULL);
17 }
-> 18 for (int i = 0; i < 5; i++) {
19 pthread_join(thread_ids[i], NULL);
20 }
21 return 0;
(lldb) thread select -t 216051
* thread #6, name = 'a.out'
frame #0: 0x00007ffff68f9918 libc.so.6`__nanosleep + 72
libc.so.6`__nanosleep:
-> 0x7ffff68f9918 <+72>: cmpq $-0x1000, %rax ; imm = 0xF000
0x7ffff68f991e <+78>: ja 0x7ffff68f9952 ; <+130>
0x7ffff68f9920 <+80>: movl %edx, %edi
0x7ffff68f9922 <+82>: movl %eax, 0xc(%rsp)
(lldb) thread select 3
* thread #3, name = 'a.out'
frame #0: 0x00007ffff68f9918 libc.so.6`__nanosleep + 72
libc.so.6`__nanosleep:
-> 0x7ffff68f9918 <+72>: cmpq $-0x1000, %rax ; imm = 0xF000
0x7ffff68f991e <+78>: ja 0x7ffff68f9952 ; <+130>
0x7ffff68f9920 <+80>: movl %edx, %edi
0x7ffff68f9922 <+82>: movl %eax, 0xc(%rsp)
(lldb) thread select -t 216048
* thread #3, name = 'a.out'
frame #0: 0x00007ffff68f9918 libc.so.6`__nanosleep + 72
libc.so.6`__nanosleep:
-> 0x7ffff68f9918 <+72>: cmpq $-0x1000, %rax ; imm = 0xF000
0x7ffff68f991e <+78>: ja 0x7ffff68f9952 ; <+130>
0x7ffff68f9920 <+80>: movl %edx, %edi
0x7ffff68f9922 <+82>: movl %eax, 0xc(%rsp)
(lldb) thread select --thread_id 216048
* thread #3, name = 'a.out'
frame #0: 0x00007ffff68f9918 libc.so.6`__nanosleep + 72
libc.so.6`__nanosleep:
-> 0x7ffff68f9918 <+72>: cmpq $-0x1000, %rax ; imm = 0xF000
0x7ffff68f991e <+78>: ja 0x7ffff68f9952 ; <+130>
0x7ffff68f9920 <+80>: movl %edx, %edi
0x7ffff68f9922 <+82>: movl %eax, 0xc(%rsp)
(lldb) help thread select
Change the currently selected thread.

Syntax: thread select <cmd-options> <thread-index>

Command Options Usage:
thread select [-t] <thread-index>

-t ( --thread_id )
Provide a thread ID instead of a thread index.

This command takes options and free-form arguments. If your arguments
resemble option specifiers (i.e., they start with a - or --), you must use
' -- ' between the end of the command options and the beginning of the
arguments.
(lldb) c
Process 215715 resuming
Process 215715 exited with status = 0 (0x00000000)
```

show more ...