At least for our Windows on Arm machine compiling with clang-cl,
it has inverted which variables get a `::` prefix.
Would not surprise me if msvc does the opposite so feel free to
revert if these tests fail for you.
Previously, when output like `"hello\nworld\n"` was produced by lldb (or
the process) the message would be sent as a single Output event. By
being a single event this causes VS Code to treat this as a single
message in the console when handling displaying and filtering in the
Debug Console.
Instead, with these changes we send each line as its own event. This
results in VS Code representing each line of output from lldb-dap as an
individual output message.
Resolves#105444
VS Code requests the `instruction` stepping granularity if the assembly
view is currently focused. By implementing `StepGranularity`, we can
hence properly single-step through assembly code.
This commit takes advantage of the recently introduced
`SBFrame::IsHidden` to show those hidden frames as "subtle" frames in
the UI. E.g., VS Code hides those stack frames by default, and renders
them as grayed out frames, in case the user decides to show them in the
stack trace
The strings this test is using seem to consistently fail to match
against the expected values when built & run targeting Windows amd64.
This PR updates them to the expected values.
To fix the test and avoid over-specifying for a specific platform, use
`assertIn(<target-substring>,...)` to see if we've got the correct
target label instead of comparing the demangler output for an exact
string match.
---------
Co-authored-by: kendal <kendal@thebrowser.company>
Frequently, while troubleshooting user's debugging issues in VScode, we
would like to know lldb version so that we can confirm if certain
patch/feature is in or not.
This PR adds version string into `initialize` response so that telemetry
can track it.
---------
Co-authored-by: jeffreytan81 <jeffreytan@fb.com>
Adding a "port" property to the VsCode "attach" command likely extends
the functionality of the debugger configuration to allow attaching to a
process using PID or PORT number.
Currently, the "Attach" configuration lets the user specify a pid. We
tell the user to use the attachCommands property to run "gdb-remote ".
Followed the below conditions for "attach" command with "port" and "pid"
We should add a "port" property. If port is specified and pid is not,
use that port to attach. If both port and pid are specified, return an
error saying that the user can't specify both pid and port.
Ex - launch.json
{
"version": "0.2.0",
"configurations": [
{
"name": "lldb-dap Debug",
"type": "lldb-dap",
"request": "attach",
"gdb-remote-port":1234,
"program": "${workspaceFolder}/a.out",
"args": [],
"stopOnEntry": false,
"cwd": "${workspaceFolder}",
"env": [],
}
]
}
---------
Co-authored-by: Santhosh Kumar Ellendula <sellendu@hu-sellendu-hyd.qualcomm.com>
Co-authored-by: Santhosh Kumar Ellendula <sellendu@hu-sellendu-lv.qualcomm.com>
The Platform class currently has two functions to resolve an executable:
`ResolveExecutable` and `ResolveRemoteExecutable`. The former strictly
deals with local files while the latter can handle potentially remote
files. I couldn't figure out why the distinction matters, at the latter
is a super-set of the former.
To make things even more confusion, we had a similar but not identical
implementation in RemoteAwarePlatform where its implementation of
`ResolveExecutable` could handle remote files. To top it all off, we had
copy-pasted implementation, dead code included in
`PlatformAppleSimulator` and `PlatformRemoteDarwinDevice`.
I went ahead and unified all the different implementation on the
original `ResolveRemoteExecutable` implementation. As far as I can tell,
it should work for every other platform, and the test suite (on macOS)
seems to agree with me, except for a small wording change.
Use the packaging [1] module for parsing version numbers, instead of
pkg_resources which is distributed with setuptools. I recently switched
over to using the latter, knowing it was deprecated (in favor of the
packaging module) because it comes with Python out of the box. Newer
versions of setuptools have removed `pkg_resources` so we have to use
packaging.
[1] https://pypi.org/project/packaging/
The local PTY is not available for the remotely executed lldb-server to
pass the test. Also, in general, we cannot execute the local lldb-server
instance because it could be compiled for the different system/cpu
target.
The TestGdbRemoteLibrariesSvr4Support test failed in case of Linux
x86_64 host and Linux Aarch64 target. Installing libraries to the remote
target is not enough. This test actively uses self.getBuildDir() and
os.path.realpath() which does not work in case of the remote target. So,
disable this test for remote target now.
A synthetic child provider might need to do considerable amount of work
to compute the number of children. lldb-dap is currently calling that
for all synthethic variables, but it's only actually using the value for
values which it deems to be "indexed" (which is determined by looking at
the name of the first child). This patch reverses the logic so that
GetNumChildren is only called for variables with a suitable first child.
The don't currently work (and they're also not particularly useful,
since all of the remote stuff happens inside lldb).
This saves us from annotating tests one by one.
VSCode will automatically ask for the children (in structured form) so
there's no point in sending the textual representation. This can make
displaying hover popups for complex variables with complicated data
formatters much faster. See discussion on #77026 for context.
ResolveCommand will not succeed for an alias command with arguments, and
the code wasn't providing any. Replace that with explicit query(ies) for
the existence of a command with the given name.
The tests TestPty and TestPtyServer use the Unix specific python builtin
module termios. They are failed in case of Windows host and Linux
target. Disable them for Windows host too.
Windows path is case insensitive. Tests `test_QMemTags_packets` and
`test_qMemTags_packets` will use the same build dir and conflict. Added
a suffix to resolve conflicts.
It is necessary to transfer the test file to/from the really remote
target (for example Windows host and Linux target). Also ignore chmod
check in case of the Windows host.
While adding a UI feature in VSCode to toggle hex/dec in variables view
window. I noticed that it does not work after second toggle. Then I
noticed that there is a bug that we only explicitly set hex format not
reset back to default during further toggle. The new test demonstrates
the bug.
This PR resets the format back to default if not using hex. One
complexity is that, we explicitly set registers value format to
AddressInfo, which shouldn't be overridden by default or hex settings.
---------
Co-authored-by: jeffreytan81 <jeffreytan@fb.com>
Summary:
'test_exit_status_message_sigterm' is failing due to 'psutil' dependency
introduced in PR #89405. This fix removes 'deque' dependency and checks
if 'psutil' can be imported before running the test. If 'psutil' cannot
be imported, it emits a warning and skips the test.
Test Plan:
./bin/llvm-lit -sv
/path-to-llvm-project/lldb/test/API/tools/lldb-dap/console/TestDAP_console.py
--filter=tools/lldb-dap/console/TestDAP_console.py
Reviewers:
@jeffreytan81,@clayborg,@kusmour, @JDevlieghere,@walter-erquinigo
Subscribers:
Tasks:
lldb-dap
Tags:
This patch provides the initial implementation for the "Step Into
Specific/Step In Targets" feature in VSCode DAP.
The implementation disassembles all the call instructions in step range
and try to resolve operand name (assuming one operand) using debug info.
Later, the call target function name is chosen by end user and specified
in the StepInto() API call.
It is v1 because of using the existing step in target function name API.
This implementation has several limitations:
* Won't for indirect/virtual function call -- in most cases, our
disassembler won't be able to solve the indirect call target
address/name.
* Won't work for target function without debug info -- if the target
function has symbol but not debug info, the existing
ThreadPlanStepInRange won't stop.
* Relying on function names can be fragile -- if there is some middle
glue/thunk code, our disassembler can only resolve the glue/thunk code's
name not the real target function name. It can be fragile to depend
compiler/linker emits the same names for both.
* Does not support step into raw address call sites -- it is a valid
scenario that in Visual Studio debugger, user can explicitly choose a
raw address to step into which land in the function without debug
info/symbol, then choose UI to load the debug info on-demand for that
module/frame to continue exploring.
A more reliable design could be extending the ThreadPlanStepInRange to
support step in based on call-site instruction offset/PC which I will
propose in next iteration.
---------
Co-authored-by: jeffreytan81 <jeffreytan@fb.com>
Summary:
When the target inferior process that is being debugged exits in lldb
command line, it emits following message:
`Process 4049526 exited with status = -1 (0xffffffff) debugserver died
with signal SIGTERM`
lldb-dap on the other hand does not emit a similar message. This PR adds
the same status message to lldb-dap.
Test Plan:
In VSCode debug any target and hit stop mode, kill lldb-server and
observe an exit status message similar to the following: Process 2167677
exited with status = -1 (0xffffffff) debugserver died with signal
SIGTERM
Reviewers:
@jeffreytan81,@clayborg,@kusmour,
Subscribers:
Tasks:
lldb-dap
Tags:
There are users reporting saving minidump from lldb-dap does not work.
Turns out our stack trace request always evaluate a function call which
caused JIT object file like "__lldb_caller_function" to be created which
can fail minidump builder to get its module size.
This patch fixes "getModuleFileSize" for ObjectFileJIT so that module
list can be saved. I decided to create a lldb-dap test so that this
end-to-end functionality can be validated from our tests (instead of
only command line lldb).
The patch also improves several other small things in the workflow:
1. It logs any minidump stream failure so that it is easier to find out
what stream saving fails. In future, we should show process and error to
end users.
2. It handles error from "getModuleFileSize" llvm::Expected<T> otherwise
it will complain the error is not handled.
---------
Co-authored-by: jeffreytan81 <jeffreytan@fb.com>
The timeout for this test was set to 1.0s which is very low, it should
be a default of 10s and be increased by a factor of 10 if ASAN is
enabled. This will help reduce the falkiness of the test, especially in
ASAN builds.
