XFAIL nodefaultlib.cpp on darwin - the test does not pass there
XFAIL TestGdbRemoteMemoryAllocation on windows - memory is allocated
with incorrect permissions
This patch adds support for the _M and _m gdb-remote packets, which
(de)allocate memory in the inferior. This works by "injecting" a
m(un)map syscall into the inferior. This consists of:
- finding an executable page of memory
- writing the syscall opcode to it
- setting up registers according to the os syscall convention
- single stepping over the syscall
The advantage of this approach over calling the mmap function is that
this works even in case the mmap function is buggy or unavailable. The
disadvantage is it is more platform-dependent, which is why this patch
only works on X86 (_32 and _64) right now. Adding support for other
linux architectures should be easy and consist of defining the
appropriate syscall constants. Adding support for other OSes depends on
the its ability to do a similar trick.
Differential Revision: https://reviews.llvm.org/D89124
Per the DAP spec for SetBreakpoints [1], the way to clear breakpoints is: `To clear all breakpoint for a source, specify an empty array.`
However, leaving the breakpoints field unset is also a well formed request (note the `breakpoints?:` in the `SetBreakpointsArguments` definition). If it's unset, we have a couple choices:
1. Crash (current behavior)
2. Clear breakpoints
3. Return an error response that the breakpoints field is missing.
I propose we do (2) instead of (1), and treat an unset breakpoints field the same as an empty breakpoints field.
[1] https://microsoft.github.io/debug-adapter-protocol/specification#Requests_SetBreakpoints
Reviewed By: wallace, labath
Differential Revision: https://reviews.llvm.org/D88513
When running in an ipv6-only environment where `AF_INET` sockets are not available, many lldb tests (mostly gdb remote tests) fail because things like `127.0.0.1` don't work there.
Use `localhost` instead of `127.0.0.1` whenever possible, or include a fallback of creating `AF_INET6` sockets when `AF_INET` fails.
Reviewed By: labath
Differential Revision: https://reviews.llvm.org/D87333
Caused by D86662. The fix is only checking some fields when the expect_debug_info_size flag is true. For some reason this was not failing on a local linux machine.
The tests seem to be timing out in all linux bots. Need further analysis.
Revert "run in terminal"
This reverts commit de6caf871be79dc7549aebe4e4fb57d52f6ed202.
The Symbol Status in modules view is simplified so that only when the module has debug info and its size is non-zero, will the status message be displayed. The symbol status message is renamed to debug info size and flag message like "Symbols not found" and "Symbols loaded" is deleted.
Differential Revision: https://reviews.llvm.org/D86662
This patch removes the rather confusing LLDB_LIB_DIR and LLDB_IMPLIB_DIR
environment variables. They are confusing because LLDB_LIB_DIR would
point to the bin subdirectory in the build root while LLDB_IMPLIB_DIR
would point to the lib subdirectory. The reason far this was
LLDB.framework, which gets build under bin.
This patch replaces their uses with configuration.lldb_framework_path
and configuration.lldb_libs_dir respectively.
Differential revision: https://reviews.llvm.org/D86817
1. Extended the gdb-remote communication related classes with disk file/directory
completion functions;
2. Added two common completion functions RemoteDiskFiles and
RemoteDiskDirectories based on the functions above;
3. Added completion for these commands:
A. platform get-file <remote-file> <local-file>;
B. platform put-file <local-file> <remote-file>;
C. platform get-size <remote-file>;
D. platform settings -w <remote-dir>;
E. platform open file <remote-file>.
4. Added related tests for client and server;
5. Updated docs/lldb-platform-packets.txt.
Reviewed By: labath
Differential Revision: https://reviews.llvm.org/D85284
Rename the existing expectedFailure to expectedFailureIfFn to better
describe its purpose and provide an overload for
unittest2.expectedFailure in decorators.py.
The current code fails when the first stderr line doesn't match the
given regex to parse the PID. This patch changes the code to read the
first 10 lines before giving up. It also adds tracing for the simctl
commands.
This test was added in D74217 (and the `.categories` file later added in ccf1c30cde6e1e763e7c9cdd48a609a805166699) around the same time I moved the test tree from `lldb/packages/Python/lldbsuite/test` to `lldb/test/API` (D71151). Since this got lost in the move, it isn't running. (I introduced an intentional syntax error, and `ninja check-lldb` passes).
I moved it to the correct location, and now it runs and passes -- locally, at least -- as `ninja check-lldb-api-tools-lldb-server-registers-target-xml-reading`.
If a module has debug info, the size of debug symbol will be displayed after the Symbols Loaded Message for each module in the VScode modules view.{F12335461}
Reviewed By: wallace, clayborg
Differential Revision: https://reviews.llvm.org/D83731
Summary: If a module has debug info, the size of debug symbol will be displayed after the Symbols Loaded Message for each module in the VScode modules view.{F12335461}
Reviewers: wallace, clayborg
Reviewed By: wallace, clayborg
Subscribers: cfe-commits, aprantl, lldb-commits
Tags: #lldb, #clang
Differential Revision: https://reviews.llvm.org/D83731
Reduce sleep and time outs in GDB remote testcases to one default value
for each. Stop passing these values around and always use the default
instead.
Differential revision: https://reviews.llvm.org/D83904
Summary:
test_terminate_commands is flaky on LLDB Arm buildbot as well. It was already
being skipped for aarch64. I am going to mark it skipped for Arm too.
Tags: #lldb
Differential Revision: https://reviews.llvm.org/D81978
Always clean up subprocesses on tear down instead of relying on the
caller to do so. This is not only less error prone but also means the
tests can be more concise.
Differential revision: https://reviews.llvm.org/D83787
Original commit c60216db15132401ff60c08ccef899321f63b6b6.
The test can only run on Darwin because of how it was setup, so I'm
enforcing that.
Summary:
Test Plan:
Reviewers:
Subscribers:
Tasks:
Tags:
This reverts commit 881af6eb0030986876d3b80668193e5c3c04a87c.
Revert "[lldb-vscode] Add Compile Unit List to Modules View"
This reverts commit 03ef61033ff5e1e40518f14f642e4ad8d686974c.
Revert "[lldb-vscode] Add Support for Module Event"
This reverts commit f7f80159753ba725f7e32529fcc369bc358efbb3.
The debian buildbot has reported issues with the modules test.
http://lab.llvm.org:8011/builders/lldb-x86_64-debian/builds/13767/steps/test/logs/stdio
Reverting it for now.
For some reason this works on the original author's machine, but not on my. So I'm using a safer approach of using an unstripped dynamic library to place breakpoints on. The author was placing a breakpoint on the main symbol of a stripped library and for some reason it worked on their machine, but it shouldn't have...
Offender diff: D82477
Summary: User can expand and check compile unit list for the modules that have debug info.
Reviewers: wallace, clayborg
Reviewed By: clayborg
Subscribers: aprantl, lldb-commits
Tags: #lldb
Differential Revision: https://reviews.llvm.org/D83072
Summary:
Whenever a module is created, removed or changed, lldb-vscode is now sending an event that can be interpreted by the IDE so that modules can be rendered in the IDE, like the tree view in this screenshot
{F12229758}
Reviewers: wallace, clayborg, kusmour, aadsm
Reviewed By: clayborg
Subscribers: cfe-commits, labath, lldb-commits
Tags: #lldb, #clang
Differential Revision: https://reviews.llvm.org/D82477
Summary:
These two tests are flaky on lldb Arm buildbot as well. They are already
being skipped for aarch64. I am going to mark them skipped for Arm.
Tags: #lldb
Differential Revision: https://reviews.llvm.org/D81978
Summary:
This redoes https://reviews.llvm.org/D79726 and fixes two things.
- The logic that determines whether to automatically disconnect during the tear down is not very dumb compared to the original implementation. Each test will determine whether to do that or not.
- The terminate commands and terminate event were being sent after the disconnect response was sent to the IDE. That was not good, as VSCode stops the debug session as soon as it receives a disconnect response. Now, the terminate event and terminateEvents are being executed before the disconnect response is sent. This ensures that any connection between the IDE and lldb-vscode is alive while the terminate commands are executed. Besides, it also allows displaying the output of the terminate commands on the debug console, as it's still alive.
Reviewers: clayborg, aadsm, kusmour, labath
Subscribers: lldb-commits
Tags: #lldb
Differential Revision: https://reviews.llvm.org/D81978
Summary:
Recently I've noticed that VSCode sometimes doesn't send the terminateDebuggee flag within the disconnectRequest,
even though lldb-vscode sets the terminateDebuggee capability correctly.
This has been causing that inferiors don't die after the debug session ends, and many users have reported issues because of this.
An easy way to mitigate this is to set better default values for the terminateDebuggee field in the disconnect request.
I'm assuming that for a launch request, the default will be true, and for attach it'll be false.
Reviewers: clayborg, labath, aadsm
Subscribers: lldb-commits
Tags: #lldb
Differential Revision: https://reviews.llvm.org/D81200
One can have multiple simulator runtimes installed, supporting
various generations of OSs. The logic in TestAppleSimulatorOSType
might select a rnutime older than the one targeted by the current
tools, preventing the executable from running. This commit changes
the test to look for the most recent runtime available instead.
Many tests use (commented out) print statement for debugging the test
itself. This patch adds a new trace method to lldbtest to reuse the
existing tracing infrastructure and replace these print statements.
Differential revision: https://reviews.llvm.org/D80448
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
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
[intel-pt] Improve the way the test determines whether to run
- Now I'm creating a default value for the new test parameter
- I fixed a small mistake in the skipping logic of the test
... I forgot to clear the cmake cache when testing my diff
Summary:
@labath raised a concern on the way I was skipping this test. I think that was
fair and I found a better way.
Now I'm skipping if the CMAKE flag LLDB_BUILD_INTEL_PT is false.
I added an enabled_plugins entry in the dotest configuration, which gets
set by lit or lldb-dotest. The only available plugin right now is
'intel-pt', but I imagine it will be useful in the future for other
kinds of plugins that get determined at configuration time. I didn't
want to add a new argument option --enable-intel-pt or something or the
sort, as it wouldn't be useful for other cases.
Reviewers: labath, clayborg
Subscribers: lldb-commits, labath
Tags: #lldb
Differential Revision: https://reviews.llvm.org/D77452
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
