Summary:
This patch fixes logging to log incoming packets which was removed during a refactor.
We also enable logging to a "vscode.txt" file for each lldb-vscode test by creating the log file in the build artifacts directory for each test. This allows users to see the packets for their tests if needed and the log file is in a directory that will be removed after tests have been run.
Reviewers: labath, aadsm, serhiy.redko, jankratochvil, xiaobai, wallace
Subscribers: lldb-commits
Tags: #lldb
Differential Revision: https://reviews.llvm.org/D74566
This commit fixes an issue with lldb-vscode failing to run programs that
use different architecture/platform than the "empty" in the target.
Original implementation was creating a default target without specifying
the target architecture, platform or program, and then would set
executable file through SBLaunchInfo, assuming that this would update
architecture and platform accordingly. However this wasn't really
happening, and architecture and platform would remain at whatever values
were in the "empty" target. The simple solution is to create target
already for a desired architecture and platform.
Function request_attach is updated in a similar fashion.
This commit also adds new JSON properties to "launch" and "attach"
packets to allow user to override desired platform and architecture.
This might be especially important for cases where information in ELF is
not enough to derive those values correctly.
New code has a behavior similar to LLDB MI [1], where typically IDE would
specify target file with -file-exec-and-symbols, and then only do -exec-run
command that would launch the process. In lldb-vscode those two actions are
merged into one request_launch function. Similarly in the interpreter
session, user would first do "file" command, then "process launch"
Differential Revision: https://reviews.llvm.org/D70847
Signed-off-by: Anton Kolesov <anton.kolesov@synopsys.com>
Summary: The VS Code DAP expects on response for each breakpoint that was requested. If we responsd with multiple entries for one breakpoint the VS Code UI gets out of date. Currently the VS code DAP doesn't handle one breakpoint with multiple locations. If this ever gets fixed we can modify our code.
Reviewers: labath
Subscribers: lldb-commits
Tags: #lldb
Differential Revision: https://reviews.llvm.org/D73665
Summary: This option is not used anymore and has been replaced by the env var LLDBVSCODE_LOG.
Reviewers: clayborg
Subscribers: lldb-commits
Tags: #lldb
Differential Revision: https://reviews.llvm.org/D74266
Summary:
Completion requests are causing some problems in the debugger, which is explained in the comment in the code.
I'm disabling it for now until we have time to do a good implementation of it.
Reviewers: clayborg
Subscribers: lldb-commits
Tags: #lldb
Differential Revision: https://reviews.llvm.org/D74264
Summary:
There was a bug on LLDB VSCode where there was the following behavior:
//Code
```
struct foo {
int bar:
};
...
foo my_foo = {10};
```
Trying to auto-complete my_foo.b with my_foo.bar resulted instead with my_foo.my_foo.bar
This diff fixes this bug and adds some tests to check correct behavior.
It also fixes the same bug using the arrow operator (->) when user manually requests completions.
TODO: Fix bug where no recommended completions are automatically shown with arrow operator
{F11249959}
{F11249958}
Reviewers: wallace
Reviewed By: wallace
Subscribers: teemperor, labath, lldb-commits
Tags: #lldb
Differential Revision: https://reviews.llvm.org/D73506
This is how it should've been and brings it more in line with
std::string_view. There should be no functional change here.
This is mostly mechanical from a custom clang-tidy check, with a lot of
manual fixups. It uncovers a lot of minor inefficiencies.
This doesn't actually modify StringRef yet, I'll do that in a follow-up.
"The debug adapter supports the delayed loading of parts of the stack,
which requires that both the 'startFrame' and 'levels' arguments and the
'totalFrames' result of the 'StackTrace' request are supported."
Lack of this field makes VSCode incorrectly display stack traces information
D71034
Summary:
The DAP has a completion request that has been unimplemented. It allows showing autocompletion tokens inside the Debug Console.
I implemented it in a very simple fashion mimicking what the user would see when autocompleting an expression inside the CLI.
There are two cases: normal variables and commands. The latter occurs when a text is prepepended with ` in the Debug Console.
These two cases work well and have tests.
Reviewers: clayborg, aadsm
Subscribers: lldb-commits
Tags: #lldb
Differential Revision: https://reviews.llvm.org/D69873
Summary: _setmode in assert will not run when build with NDEBUG
Reviewers: mstorsjo, labath, amccarth
Reviewed By: labath
Subscribers: lldb-commits
Tags: #lldb
Differential Revision: https://reviews.llvm.org/D69612
Summary:
`lldb-vscode` concatenates a string of sourceMap entries
specified in the config, but fails to put a space between
each entry, which causes the settings command to fail.
This patch adds a space between each mapping.
Patch by Richard Howell
Differential Revision: https://reviews.llvm.org/D67569
llvm-svn: 373016
That change didn't contain any explanation for this bit. There shouldn't
be any need for a check for MinGW ifdefs here, as long as the include
uses lowercase windows.h (as is used consistently elsewhere in
the llvm projects).
Differential Revision: https://reviews.llvm.org/D67894
llvm-svn: 372656
This silences warnings about comparison of integers between unsigned
long long (which is what the Windows SOCKET type is) and signed int
when building in MinGW mode.
Differential Revision: https://reviews.llvm.org/D67863
llvm-svn: 372486
Summary:
This can help `lldb-vscode` handle launch commands associate with remote platform
attach request have field `attachCommands` to handle attach specific commands
add a corresponding one for launch request
if no launch command is provided, create a new target and launch; otherwise, execute the launch command
Differential Revision: https://reviews.llvm.org/D65363
Patch by Wanyi Ye <kusmour@gmail.com>
llvm-svn: 369296
Summary:
Modify the way LLDB.framework tools are collected. This allows for better fine-tuning of the install behavior downstream. Each target calls `lldb_add_to_framework()` individually. When entering the function, the target exists and we can tweak its very own post-build and install steps. This was not possible with the old `LLDB_FRAMEWORK_TOOLS` approach.
No function change otherwise.
This is a reduced follow-up from the proposal in D61952.
Reviewers: xiaobai, compnerd, JDevlieghere
Reviewed By: JDevlieghere
Subscribers: clayborg, friss, ki.stfu, mgorny, lldb-commits, labath, #lldb
Tags: #lldb
Differential Revision: https://reviews.llvm.org/D62472
llvm-svn: 361946
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
SBError::GetCString() returns a pointer to a string owned by the SBError
object. The code here was calling GetCString on a temporary and using
the returned pointer after the temporary was destroyed.
Differential Revision: https://reviews.llvm.org/D59400
llvm-svn: 356227
If an invalid program is specified, lldb-vscode will send back a
response with "success" = false, but then will continue executing the
rest of request_launch(), try to launch the program anyway and try to
send another response (possibly using the `response` object after it was
moved).
This change adds a return statement so we stop executing the handler
after producing the first failing response.
Differential Revision: https://reviews.llvm.org/D59340
llvm-svn: 356110
I changed the variable to an unsigned to get rid of a signed and
unsigned compare without realizing the value could be negative. This
fixes the assert instead.
llvm-svn: 355708
Previously if an invalid program was specified, there was a bug
which, when we attempted to launch the program, would report that
the operation succeeded, causing LLDB to then hang while waiting
indefinitely to receive some events from the process.
After this patch, when an invalid program is specified, we immediately
return to vs code with an error message that indicates that the
program can not be found.
Differential Revision: https://reviews.llvm.org/D59114
llvm-svn: 355656
Windows can't use standard i/o system calls such as read and write
to work with sockets, it instead needs to use the specific send
and recv calls. This complicates matters for the debug adapter,
since it needs to be able to work in both server mode where it
communicates over a socket, as well as non-server mode where it
communicates via stdin and stdout. To abstract this out, I've
introduced a class IOStream which hides all these details and
exposes a read/write interface that does the right on each
platform.
Differential Revision: https://reviews.llvm.org/D59104
llvm-svn: 355637
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
Summary:
If we build LLDB.framework, dependant tools need appropriate RPATHs in both locations, the build-tree (for testing) and the install-tree (for deployment). Luckily, CMake can handle it for us: https://gitlab.kitware.com/cmake/community/wikis/doc/cmake/RPATH-handling.
* In the build-tree, tools use the absolute path to the framework's actual output location.
* In the install-tree, tools get a list of RPATHs to look for the framework when deployed.
`LLDB_FRAMEWORK_INSTALL_DIR` is added to the `CMAKE_INSTALL_PREFIX` to change the relative location of LLDB.framework in the install-tree.
If it is not empty, it will be added as an additional RPATH to all dependant tools (so they are functional in the install-tree).
If it is empty, LLDB.framework goes to the root and tools will not be functional in the directory structure of the LLVM install-tree.
For historical reasons `LLDB_FRAMEWORK_INSTALL_DIR` defaults to "Library/Frameworks".
Reviewers: xiaobai, JDevlieghere, aprantl, clayborg
Reviewed By: JDevlieghere
Subscribers: ki.stfu, mgorny, lldb-commits, #lldb
Differential Revision: https://reviews.llvm.org/D55330
llvm-svn: 350392
This patch simplifies boolean expressions acorss LLDB. It was generated
using clang-tidy with the following command:
run-clang-tidy.py -checks='-*,readability-simplify-boolean-expr' -format -fix $PWD
Differential revision: https://reviews.llvm.org/D55584
llvm-svn: 349215
Summary:
Highlighing junk data on VSCode can send a query for evaluate which
fails. In particular cases on Windows, this the error message can end
up as a c-string of [-35,-35,-35,-35,...]. Attempting to emplace this
as the error message causes an assert failure.
Prior to emplacing the error message, confirm that it is valid UTF8 to
eliminate errors such as mentione above.
Reviewers: xiaobai, clayborg
Reviewed By: clayborg
Differential Revision: https://reviews.llvm.org/D53008
llvm-svn: 346988
Summary:
The DAP on vscode uses a JavaScript `number` for identifiers while the
Visual Studio version uses a C# `Int` for identifiers. lldb-vscode is
bit shifting identifiers 32 bits and then bitwise ORing another 32 bit
identifier into a 64 bit id to form a unique ID. Change this to
a a partitioning of the 32 bits that makes sense for the data types.
Reviewers: clayborg
Differential Revision: https://reviews.llvm.org/D53599
llvm-svn: 346346
Summary:
On rare occasions, the address, instruction and arguments of a line of
assembly in the CreateSource printout would reach > 60 characters. The
function would integer overflow and try to indent a line by `0xfff...`.
Change the calculated offset to be the maximum of 60 or
`line_strm.str().size()`
Reviewers: clayborg, xiaobai
Reviewed By: clayborg
Differential Revision: https://reviews.llvm.org/D52745
llvm-svn: 346179
Summary:
A file opened in text mode on Windows will have `\n` automatically changed to `13,10` while Darwin and Linux leave it as `10`.
Set the file to binary mode to avoid this automatic conversion so that Darwin, Linux and Windows have equivalent treatment of `\r`.
Reviewers: clayborg, xiaobai
Reviewed By: clayborg
Subscribers: emaste, ki.stfu, mgorny, eraman, JDevlieghere, mgrang
Differential Revision: https://reviews.llvm.org/D52672
llvm-svn: 346174
Summary: The readme was missing "-" characters to enable links
Patch by Nathan Lanza <nathan@lanza.io>
Differential Revision: https://reviews.llvm.org/D52069
llvm-svn: 342266
Include PosixAPI.h to get a PATH_MAX definition and replace CreateEvent
with CreateEventObject to avoid conflicts with the windows.h definition
of CreateEvent to CreateEventW.
llvm-svn: 339920
This patch adds a new lldb-vscode tool that speaks the Microsoft Visual Studio Code debug adaptor protocol. It has full unit tests that test all packets.
This tool can be easily packaged up into a native extension and used with Visual Studio Code, and it can also be used by Nuclide
Differential Revision: https://reviews.llvm.org/D50365
llvm-svn: 339911