Summary:
Running `vsce package` to package lldb-vscode as an installable .vsix file errors with:
```
ERROR Invalid publisher name 'llvm.org'. Expected the identifier of a publisher, not its human-friendly name.
```
This patch fixes the publisher name and bumps a required dependency so that `vsce package` succeeds.
Reviewers: clayborg
Reviewed By: clayborg
Tags: #lldb
Differential Revision: https://reviews.llvm.org/D80569
Summary:
It turns out that the order in which we provide completions for expressions is
nondeterministic. This leads to confusing user experience and also breaks the
reproducer tests (as two LLDB tests can go out of sync due to the
non-determinism in the completion lists)
The reason for the non-determinism is that the CompletionConsumer informs us
about decls in the order in which it finds declarations in the lookup store of
the DeclContexts it visits (mainly this snippet in SemaLookup.cpp):
``` lang=c++
// Enumerate all of the results in this context.
for (DeclContextLookupResult R :
Load ? Ctx->lookups()
: Ctx->noload_lookups(/*PreserveInternalState=*/false)) {
[...]
```
This storage of the lookup is sorted by pointer values (see the hash of
`DeclarationName`) and can therefore be non-deterministic. The LLDB code
completion consumer that receives these calls originally expected that the order
of declarations is defined by Clang, but it seems the API expects the client to
provide an order to the completions.
This patch fixes the issue as follows:
* We sort the completions we get from Clang alphabetically and also by the
priority value we get from Clang (with priority value sorting having precedence
over the alphabetical sorting)
* We make all the functions/variables that touch a completion before the sorting
const-qualified. The idea is that this should prevent that we never have
observable side-effect from touching these declarations in a non-deterministic
order (e.g., we don't try to complete the type by accident).
This way we behave like the other parts of Clang which also sort the results by
some deterministic value (usually the name or something computed from a name,
e.g., edit distance to a given string).
We most likely also need to fix the Clang code to make the loop I listed above
deterministic to prevent these issues in the future (tracked in rdar://63442513
). This wouldn't replace the functionality provided in this patch though as we
would still need the priority and overall alphabetical sorting.
Note: I had to increase the lldb-vscode completion limit to 100 as the tests
look for strings that aren't in the first 50 results anymore due to variable
names starting with letters like 'v' (which are now always shown much further
down in the list due to the alphabetical sorting).
Fixes rdar://63200995
Reviewers: JDevlieghere, clayborg
Reviewed By: JDevlieghere
Subscribers: mgrang, abidh
Differential Revision: https://reviews.llvm.org/D80292
Print a little snippet before exiting when passed unrecognized
arguments. The goal is twofold:
- Point users to lldb --help.
- Make it clear that we exited the debugger.
There appears to be consensus in D80165 that this is the desired
behavior and I personally agree.
Differential revision: https://reviews.llvm.org/D80226
Summary: Adding this in line with "stopCommands" and "exitCommands" so that we can run commands at the end of the debugging session.
Reviewers: clayborg, wallace, labath
Reviewed By: clayborg, labath
Subscribers: lldb-commits
Tags: #lldb
Differential Revision: https://reviews.llvm.org/D79726
Before the transition to libOption it was possible to specify arguments
for the inferior without -- as long as they didn't start with a dash.
For example, the following invocations should all behave the same:
$ lldb inferior inferior-arg
$ lldb inferior -- inferior-arg
$ lldb -- inferior inferior-arg
This patch fixes that behavior, documents it and adds a test to cover
the different combinations.
Differential revision: https://reviews.llvm.org/D80165
If the error message from qLaunchSucess included a gdb RSP
metacharacter, it could crash lldb. Apply the binary
escaping to the string before sending it to lldb; lldb
promiscuously applies the binary escaping protocol on
packets it receives.
Also fix a small bug in cstring_to_asciihex_string where
a high bit character (eg utf-8 chars) would not be
quoted correctly due to signed char fun.
Differential Revision: https://reviews.llvm.org/D79614
rdar://problem/62873581
MachProcess.mm uses a TARGET_OS_ macro without directly including
TargetConditionals.h. This currently works as we get the header
as an indirect dependency, but might not in the future.
I just spent some time investigating an internal regression
caused by a similar issue, so I audited the codebase for such
cases.
Similar to
com.apple.debugserver.plist & com.apple.debugserver.internal.plist
com.apple.debugserver.applist.plist & com.apple.debugserver.applist.internal.plist
add a variant of the posix plist.
<rdar://problem/62995567>
Update CallBoardSystemServiceOpenApplication to unconditionally log
the NSError's localizedDescription to Console on app launch failure
(as it was already doing), and also to log the NSError object's
full description to the console, which may contain additional nested
error messages. I'm experimenting to find cases where we will get
more detailed information from app launch failures and will start
by logging both to the console.
<rdar://problem/62709160>
We have the option to stop running commands in batch mode when an error
occurs. When that happens we should exit the driver with a non-zero exit
code.
Differential revision: https://reviews.llvm.org/D78825
This adds an RunCommandInterpreter overload that returns an instance of
SBCommandInterpreterRunResults. The goal is to avoid having to add more
and more overloads when we need more output arguments.
Differential revision: https://reviews.llvm.org/D79120
Currently, `SBCommandInterpreterRunOptions` is defined in
`SBCommandInterpreter.h`. Given that the options are always passed by
reference, a forward declaration is sufficient.
That's not the case for `SBCommandInterpreterRunResults`, which we need
for a new overload for `RunCommandInterpreter` and that returns this new
class by value. We can't include `SBCommandInterpreter.h` because
`SBCommandInterpreter::GetDebugger()` returns SBDebugger by value and
therefore needs a full definition.
This patch moves the definition of `SBCommandInterpreterRunOptions` into
a new header. In a later patch, `SBCommandInterpreterRunResults` will
be defined in there as well, solving the aforementioned problem.
Differential revision: https://reviews.llvm.org/D79115
It seems like only the unittests are building with
BUILD_WITH_INSTALL_RPATH set to OFF. Of course when I did my last change
I only ran check-lldb-unit. Not sure why this difference exists, why
would you even install the unittest?
For the LLDB framework we do need different build and install RPATHs.
Currently that logic lives downstream. I plan to upstream that in the
near future. For now I'm just trying to make it possible to run the
test.
The install name for the Python 3 framework in Xcode is relative to
the framework's location and not the dylib itself.
@rpath/Python3.framework/Versions/3.x/Python3
This means that we need to compute the path to the Python3.framework
and use that as the RPATH instead of the usual dylib's directory.
Summary:
Currently loading core files on lldb-vscode is broken because there's a check in the attach workflow that asserts that the PID is valid, which of course fails for this case.
Hence, I'm adding a "coreFile" argument for the attach request, which does the work correctly.
I don't know how to test it effectively so that it runs on the buildbots and the debugger can in fact makes sense of it. Anyway, the change has been relatively simple.
Reviewers: labath, clayborg
Subscribers: lldb-commits
Tags: #lldb
Differential Revision: https://reviews.llvm.org/D78839
to make the code conform to llvm style better:
- avoid use of auto where the type is not obivous
- avoid StringRef::data where it is not needed
No functional change intended.
This patch threads an lldb::DescriptionLevel through the typesystem to
allow dumping the full Clang AST (level=verbose) of any lldb::Type in
addition to the human-readable source description (default
level=full). This type dumping interface is currently not exposed
through the SBAPI.
The application is to let lldb-test dump the clang AST of search
results. I need this to test lazy type completion of clang types in
subsequent patches.
Differential Revision: https://reviews.llvm.org/D78329
The SIP debugserver was calling in attach_failed_due_to_sip
haven't worked for a while; remove them. To check this
properly we'd need debugsever to call out to codesign(1) to
inspect the entitlements, or the equivalant API,
and I'm not interested in adding that at this point. SIP
is has been the default on macOS for a couple of releases
and it's expected behavior now.
<rdar://problem/59198052>
Summary:
When using source maps for a breakpoint, in order to find the actual source that breakpoint has resolved, we
need to use a query similar to what CommandObjectSource::DumpLinesInSymbolContexts does, which is the logic
used by the CLI to display the source line at a given breakpoint. That's necessary because from a breakpoint
location you only have an address, which points to the original source location, not the source mapped one.
in the setBreakpoints request handler, we haven't been doing such query and we were returning the original
source location, which was breaking the UX of VSCode, as many breakpoints were being set but not displayed
in the source file next to each line. Besides, clicking the source path of a breakpoint in the breakpoints
view in the debug tab was not working for this case, as VSCode was trying to open a non-existent file, thus
showing an error to the user.
Ideally, we should do the query mentioned above to find the actual source location to respond to the IDE,
however, that query is expensive and users can have an arbitrary number of breakpoints set. As a simpler fix,
the request sent by VSCode already contains the full source path, which exists because the user set it from
the IDE itself, so we can simply reuse it instead of querying from the SB API.
I wrote a test for this, and found out that I had to move SetSourceMapFromArguments after RunInitCommands in
lldb-vscode.cpp, because an init command used in all tests is `settings clear -all`, which would clear the
source map unless specified after initCommands. And in any case, I think it makes sense to have initCommands
run before anything the debugger would do.
Reviewers: clayborg, kusmour, labath, aadsm
Subscribers: lldb-commits
Tags: #lldb
Differential Revision: https://reviews.llvm.org/D76968
Summary:
@labath mentioned to me that test files shouldn't have a license header.
I saw this one some days ago, so I'm doing some cleaning.
Reviewers: labath, clayborg
Subscribers: lldb-commits, labath
Tags: #lldb
Differential Revision: https://reviews.llvm.org/D77328
Summary: The IDE has no packets that are sent to lldb-vscode that say which thread and frame are selected. The only way we know is we get a request for variables for a stack frame via a "scopes" request. When we receive this packet we make that thread and frame the selected thread and frame in lldb. This way when people execute lldb commands in the debug console by prefixing the expression with the backtick character, we will have the right thread and frame selected. Previously this was not updated as new stack frames were selected.
Reviewers: labath, aadsm, wallace, JDevlieghere
Subscribers: lldb-commits
Tags: #lldb
Differential Revision: https://reviews.llvm.org/D77347
* This is a reattempted commit due to a previous builtbot failure
- Now using a env var to determine whether to run the test, as
someone might have built liblldbIntelFeatures.so without intelPT
support, which would make this test fail.
Summary:
Depends on D76872.
There was no test for the Intel PT support on LLDB, so I'm creating one, which
will help making progress on solid grounds.
The test is skipped if the Intel PT plugin library is not built.
Reviewers: clayborg, labath, kusmour, aadsm
Subscribers: lldb-commits
Tags: #lldb
Differential Revision: https://reviews.llvm.org/D77107
Summary:
Depends on D76872.
There was no test for the Intel PT support on LLDB, so I'm creating one, which
will help making progress on solid grounds.
The test is skipped if the Intel PT plugin library is not built.
Reviewers: clayborg, labath, kusmour, aadsm
Subscribers: lldb-commits
Tags: #lldb
Differential Revision: https://reviews.llvm.org/D77107
Summary:
Depends on D76872.
There was no test for the Intel PT support on LLDB, so I'm creating one, which
will help making progress on solid grounds.
The test is skipped if the Intel PT plugin library is not built.
Reviewers: clayborg, labath, kusmour, aadsm
Subscribers: lldb-commits
Tags: #lldb
Differential Revision: https://reviews.llvm.org/D77107
Summary:
//reviews.llvm.org/D33035 added in 2017 basic support for intel-pt. I
plan to improve it and use it to support reverse debugging.
I fixed a couple of issues and now this plugin works again:
1. pythonlib needed to be linked against it for the SB framework.
Linking was failing because of this
2. the decoding functionality was broken because it lacked handling for
instruction events. It seems old versions of libipt, the actual decoding
library, didn't require these, but modern version require it (you can
read more here
https://github.com/intel/libipt/blob/master/doc/howto_libipt.md). These
events signal overflows of the internal PT buffer in the CPU,
enable/disable events of tracing, async cpu events, interrupts, etc.
I ended up refactoring a little bit the code to reduce code duplication.
In another diff I'll implement some basic tests.
This is a simple execution of the library:
(lldb) target create "/data/users/wallace/rr-project/a.out"
Current executable set to '/data/users/wallace/rr-project/a.out' (x86_64).
(lldb) plugin load liblldbIntelFeatures.so
(lldb) b main
Breakpoint 1: where = a.out`main + 8 at test.cpp:10, address = 0x00000000004007fa
(lldb) b test.cpp:14
Breakpoint 2: where = a.out`main + 50 at test.cpp:14, address = 0x0000000000400824
(lldb) r
Process 902754 stopped
* thread #1, name = 'a.out', stop reason = breakpoint 1.1
frame #0: 0x00000000004007fa a.out`main at test.cpp:10
7 }
8
9 int main() {
-> 10 int z = 0;
11 for(int i = 0; i < 10000; i++)
12 z += fun(z);
13
Process 902754 launched: '/data/users/wallace/rr-project/a.out' (x86_64)
(lldb) processor-trace start all
(lldb) c
Process 902754 resuming
Process 902754 stopped
* thread #1, name = 'a.out', stop reason = breakpoint 2.1
frame #0: 0x0000000000400824 a.out`main at test.cpp:14
11 for(int i = 0; i < 10000; i++)
12 z += fun(z);
13
-> 14 cout << z<< endl;
15 return 0;
16 }
(lldb) processor-trace show-instr-log
thread #1: tid=902754
0x7ffff72299b9 <+9>: addq $0x8, %rsp
0x7ffff72299bd <+13>: retq
0x4007ed <+16>: addl $0x1, %eax
0x4007f0 <+19>: leave
0x4007f1 <+20>: retq
0x400814 <+34>: addl %eax, -0x4(%rbp)
0x400817 <+37>: addl $0x1, -0x8(%rbp)
0x40081b <+41>: cmpl $0x270f, -0x8(%rbp) ; imm = 0x270F
0x400822 <+48>: jle 0x40080a ; <+24> at test.cpp:12
0x400822 <+48>: jle 0x40080a ; <+24> at test.cpp:12
```
Subscribers: mgorny, lldb-commits
Tags: #lldb
Differential Revision: https://reviews.llvm.org/D76872
Summary:
The DAP specifies the following for the SetBreakpoints request:
The breakpoints returned are in the same order as the elements of the 'breakpoints' arguments
This was not followed, as lldb-vscode was returning the breakpoints in a different order, because they were first stored into a map, and then traversed. Of course, maps normally don't preserve ordering.
See this log I captured:
-->
{"command":"setBreakpoints",
"arguments":{
"source":{
"name":"main.cpp",
"path":"/Users/wallace/fbsource/xplat/sand/test-projects/buck-cpp/main.cpp"
},
"lines":[6,10,11],
"breakpoints":[{"line":6},{"line":10},{"line":11}],
"sourceModified":false
},
"type":"request",
"seq":3
}
<--
{"body":{
"breakpoints":[
{"id":1, "line":11,"source":{"name":"main.cpp","path":"xplat/sand/test-projects/buck-cpp/main.cpp"},"verified":true},
{"id":2,"line":6,"source":{"name":"main.cpp","path":"xplat/sand/test-projects/buck-cpp/main.cpp"},"verified":true},
{"id":3,"line":10,"source":{"name":"main.cpp","path":"xplat/sand/test-projects/buck-cpp/main.cpp"},"verified":true}]},
"command":"setBreakpoints",
"request_seq":3,
"seq":0,
"success":true,
"type":"response"
}
As you can see, the order was not respected. This was causing the IDE not to be able to disable/enable breakpoints by clicking on them in the breakpoint view in the lower corner of the Debug tab.
This diff fixes the ordering problem. The traversal + querying was done very fast in O(nlogn) time. I'm keeping the same complexity.
I also updated a couple of tests to account for the ordering.
Reviewers: clayborg, aadsm, kusmour, labath
Subscribers: lldb-commits
Tags: #lldb
Differential Revision: https://reviews.llvm.org/D76891
Those fields inside of the global variable can be local variables because
they are used in only inside of one function: request_launch for launch_info
and request_attach for attach_info.
To avoid confusion an already existing local variable attach_info of
request_attach has been renamed to better reflect its purpose.
Differential Revision: https://reviews.llvm.org/D76593
Summary:
If no custom launching is used, lldb-vscode launches a program with an empty environment by default. In some scenarios, the user might want to simply use the same environment as the IDE to have a set of working environment variables (e.g. PATH wouldn't be empty). In fact, most DAPs in VSCode have this behavior by default. In other cases the user definitely needs to set their custom environment, which is already supported. To make the first case easier for the user (e.g. not having to copy the PATH to the launch.json every time they want to debug simple programs that rely on PATH), a new option is now offered. inheritEnvironment will launch the program copying its own environment, and it's just a boolean flag.
{F11347695}
Reviewers: clayborg, aadsm, diazhector98, kusmour
Subscribers: labath, JDevlieghere, lldb-commits
Tags: #lldb
Differential Revision: https://reviews.llvm.org/D74636
Summary:
https://reviews.llvm.org/D65363 introduced the launchCommands argument. However, it did not add
a corresponding definition in the package.json
Reviewers: clayborg, labath, kusmour, aadsm
Subscribers: lldb-commits
Tags: #lldb
Differential Revision: https://reviews.llvm.org/D76529
Summary:
On Linux, when executing lldb-vscode on a remote machine, lldb-vscode doesn't die after the debug session ends. It keeps trying to read JSON input to no avail.
This diff indicates lldb-vscode to stop reading after a termination event has been processed.
Reviewers: clayborg, aadsm, kusmour
Subscribers: lldb-commits
Tags: #lldb
Differential Revision: https://reviews.llvm.org/D76314
If LLDB attaches to an already running target, then structure SBAttachInfo is
used instead of SBLaunchInfo. lldb-vscode function request_attach sets some
values to g_vsc.launch_info, however this field is then not passed anywhere, so
this action has no effect. This commit removes invocation of
SBLaunchInfo::SetDetachOnError, which has no equivalent in SBAttachInfo.
File package.json doesn't describe detachOnError property for "attach" request
type, therefore it is not needed to update it.
Differential Revision: https://reviews.llvm.org/D76351
Summary:
Compiling ObjC++ with Clang modules is usually not working well and compiling
the small debugserver with modules is not worth the trouble.
Reviewers: JDevlieghere
Reviewed By: JDevlieghere
Subscribers: mgorny, JDevlieghere, lldb-commits
Tags: #lldb
Differential Revision: https://reviews.llvm.org/D74891
Jonas Devlieghere