This adds support for optionally prefixing any command with `?` and/or
`!`.
- `?` prevents the output of a commands to be printed to the console
unless it fails.
- `!` aborts the dap if the command fails.
They come in handy when programmatically running commands on behalf of
the user without wanting them to know unless they fail, or when a
critical setup is required as part of launchCommands and it's better to
abort on failures than to silently skip.
This is an extension to the protocol that emits the declaration
information along with the metadata of each variable. This can be used
by vscode extensions to implement, for example, a "goToDefinition"
action in the debug tab, or for showing the value of a variable right
next to where it's declared during a debug session.
As this is cheap, I'm not gating this information under any setting.
When this option gets enabled, descriptions of threads will be generated
using the format provided in the launch configuration instead of
generating it manually in the dap code. This allows lldb-dap to show an
output similar to the one in the CLI.
This is very similar to https://github.com/llvm/llvm-project/pull/71843
When this option gets enabled, descriptions of stack frames will be
generated using the format provided in the launch configuration instead
of simply calling `SBFrame::GetDisplayFunctionName`. This allows
lldb-dap to show an output similar to the one in the CLI.
This patch relands https://github.com/llvm/llvm-project/pull/70639
It was reverted because under certain conditions we triggered an
assertion
in `DIBuilder`. Specifically, in the original patch we called
`EmitGlobalVariable`
at the end of `CGDebugInfo::finalize`, after all the temporary `DIType`s
have
been uniqued. With limited debug-info such temporary nodes would be
created
more frequently, leaving us with non-uniqued nodes by the time we got to
`DIBuilder::finalize`; this violated its pre-condition and caused
assertions to trigger.
To fix this, the latest iteration of the patch moves
`EmitGlobalVariable` to the
beginning of `CGDebugInfo::finalize`. Now, when we create a temporary
`DIType` node as a result of emitting a variable definition, it will get
uniqued
in time. A test-case was added for this scenario.
We also now don't emit a linkage name for non-locationed constants since
LLDB doesn't make use of it anyway.
Original commit message:
"""
When an LLDB user asks for the value of a static data member, LLDB
starts
by searching the Names accelerator table for the corresponding variable
definition DIE. For static data members with out-of-class definitions
that
works fine, because those get represented as global variables with a
location
and making them eligible to be added to the Names table. However,
in-class
definitions won’t get indexed because we usually don't emit global
variables
for them. So in DWARF we end up with a single `DW_TAG_member` that
usually holds the constant initializer. But we don't get a corresponding
CU-level `DW_TAG_variable` like we do for out-of-class definitions.
To make it more convenient for debuggers to get to the value of inline
static data
members, this patch makes sure we emit definitions for static variables
with
constant initializers the same way we do for other static variables.
This also aligns
Clang closer to GCC, which produces CU-level definitions for inline
statics and also
emits these into `.debug_pubnames`.
The implementation keeps track of newly created static data members.
Then in `CGDebugInfo::finalize`, we emit a global `DW_TAG_variable` with
a
`DW_AT_const_value` for any of those declarations that didn't end up
with a
definition in the `DeclCache`.
The newly emitted `DW_TAG_variable` will look as follows:
```
0x0000007b: DW_TAG_structure_type
DW_AT_calling_convention (DW_CC_pass_by_value)
DW_AT_name ("Foo")
...
0x0000008d: DW_TAG_member
DW_AT_name ("i")
DW_AT_type (0x00000062 "const int")
DW_AT_external (true)
DW_AT_declaration (true)
DW_AT_const_value (4)
Newly added
vvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvv
0x0000009a: DW_TAG_variable
DW_AT_specification (0x0000008d "i")
DW_AT_const_value (4)
DW_AT_linkage_name ("_ZN2t2IiE1iIfEE")
```
This patch also drops the `DW_AT_const_value` off of the declaration
since we
now always have it on the definition. This ensures that the
`DWARFParallelLinker`
can type-merge class with static members where we couldn't attach the
constant
on the declaration in some CUs.
"""
Dependent changes:
* https://github.com/llvm/llvm-project/pull/71800
Currently VSCode logpoint uses `SBValue::GetValue` to get the value for
printing. This is not providing an intuitive result for std::string or
char * -- it shows the pointer value instead of the string content.
This patch improves by prefers `SBValue::GetSummary()` before using
`SBValue::GetValue()`.
---------
Co-authored-by: jeffreytan81 <jeffreytan@fb.com>
This casued asserts:
llvm/lib/IR/Metadata.cpp:689:
void llvm::MDNode::resolve(): Assertion `isUniqued() && "Expected this to be uniqued"' failed.
See comments on the PR.
This also reverts the dependent follow-up commits, see below.
> When an LLDB user asks for the value of a static data member, LLDB
> starts by searching the Names accelerator table for the corresponding
> variable definition DIE. For static data members with out-of-class
> definitions that works fine, because those get represented as global
> variables with a location and making them eligible to be added to the
> Names table. However, in-class definitions won<E2><80><99>t get indexed because
> we usually don't emit global variables for them. So in DWARF we end
> up with a single `DW_TAG_member` that usually holds the constant
> initializer. But we don't get a corresponding CU-level
> `DW_TAG_variable` like we do for out-of-class definitions.
>
> To make it more convenient for debuggers to get to the value of
> inline static data members, this patch makes sure we emit definitions
> for static variables with constant initializers the same way we do
> for other static variables. This also aligns Clang closer to GCC,
> which produces CU-level definitions for inline statics and also
> emits these into `.debug_pubnames`.
>
> The implementation keeps track of newly created static data members.
> Then in `CGDebugInfo::finalize`, we emit a global `DW_TAG_variable`
> with a `DW_AT_const_value` for any of those declarations that didn't
> end up with a definition in the `DeclCache`.
>
> The newly emitted `DW_TAG_variable` will look as follows:
> ```
> 0x0000007b: DW_TAG_structure_type
> DW_AT_calling_convention (DW_CC_pass_by_value)
> DW_AT_name ("Foo")
> ...
>
> 0x0000008d: DW_TAG_member
> DW_AT_name ("i")
> DW_AT_type (0x00000062 "const int")
> DW_AT_external (true)
> DW_AT_declaration (true)
> DW_AT_const_value (4)
>
> Newly added
> vvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvv
>
> 0x0000009a: DW_TAG_variable
> DW_AT_specification (0x0000008d "i")
> DW_AT_const_value (4)
> DW_AT_linkage_name ("_ZN2t2IiE1iIfEE")
> ```
>
> This patch also drops the `DW_AT_const_value` off of the declaration
> since we now always have it on the definition. This ensures that the
> `DWARFParallelLinker` can type-merge class with static members where
> we couldn't attach the constant on the declaration in some CUs.
This reverts commit 7c3707aea8a6f1fc245ad2862982b8a51b6c0fea.
This reverts commit cab0a19467ac2e6e1e022087f4b6cb90d55da040.
This reverts commit 317481b3c8b34b0c3f106c514e6aa39b70886110.
This reverts commit 15fc809404d4715822e5349b76dcca50eb100eec.
This reverts commit 470de2bbec7f5fdd199775aa99c68ac76f4d5c74.
When an LLDB user asks for the value of a static data member, LLDB
starts by searching the Names accelerator table for the corresponding
variable definition DIE. For static data members with out-of-class
definitions that works fine, because those get represented as global
variables with a location and making them eligible to be added to the
Names table. However, in-class definitions won’t get indexed because
we usually don't emit global variables for them. So in DWARF we end
up with a single `DW_TAG_member` that usually holds the constant
initializer. But we don't get a corresponding CU-level
`DW_TAG_variable` like we do for out-of-class definitions.
To make it more convenient for debuggers to get to the value of
inline static data members, this patch makes sure we emit definitions
for static variables with constant initializers the same way we do
for other static variables. This also aligns Clang closer to GCC,
which produces CU-level definitions for inline statics and also
emits these into `.debug_pubnames`.
The implementation keeps track of newly created static data members.
Then in `CGDebugInfo::finalize`, we emit a global `DW_TAG_variable`
with a `DW_AT_const_value` for any of those declarations that didn't
end up with a definition in the `DeclCache`.
The newly emitted `DW_TAG_variable` will look as follows:
```
0x0000007b: DW_TAG_structure_type
DW_AT_calling_convention (DW_CC_pass_by_value)
DW_AT_name ("Foo")
...
0x0000008d: DW_TAG_member
DW_AT_name ("i")
DW_AT_type (0x00000062 "const int")
DW_AT_external (true)
DW_AT_declaration (true)
DW_AT_const_value (4)
Newly added
vvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvv
0x0000009a: DW_TAG_variable
DW_AT_specification (0x0000008d "i")
DW_AT_const_value (4)
DW_AT_linkage_name ("_ZN2t2IiE1iIfEE")
```
This patch also drops the `DW_AT_const_value` off of the declaration
since we now always have it on the definition. This ensures that the
`DWARFParallelLinker` can type-merge class with static members where
we couldn't attach the constant on the declaration in some CUs.
This reverts commit 4909814c08fdf4ec8bd9dad4f157d03de7c3c800.
Following LLDB patch had to be reverted due to Linux test failures:
```
ef3febadf606c2fc4f1ad8d85a7ecdde16e4cbb3
```
Since without that LLDB patch the LLDB tests would fail, revert
this clang patch for now.
When an LLDB user asks for the value of a static data member, LLDB
starts by
searching the Names accelerator table for the corresponding variable
definition
DIE. For static data members with out-of-class definitions that works
fine,
because those get represented as global variables with a location and
making them
eligible to be added to the Names table. However, in-class definitions
won’t get
indexed because we usually don't emit global variables for them. So in
DWARF
we end up with a single `DW_TAG_member` that usually holds the constant
initializer.
But we don't get a corresponding CU-level `DW_TAG_variable` like we do
for
out-of-class definitions.
To make it more convenient for debuggers to get to the value of inline
static data members,
this patch makes sure we emit definitions for static variables with
constant initializers
the same way we do for other static variables. This also aligns Clang
closer to GCC, which
produces CU-level definitions for inline statics and also emits these
into `.debug_pubnames`.
The implementation keeps track of newly created static data members.
Then in
`CGDebugInfo::finalize`, we emit a global `DW_TAG_variable` with a
`DW_AT_const_value` for
any of those declarations that didn't end up with a definition in the
`DeclCache`.
The newly emitted `DW_TAG_variable` will look as follows:
```
0x0000007b: DW_TAG_structure_type
DW_AT_calling_convention (DW_CC_pass_by_value)
DW_AT_name ("Foo")
...
0x0000008d: DW_TAG_member
DW_AT_name ("i")
DW_AT_type (0x00000062 "const int")
DW_AT_external (true)
DW_AT_declaration (true)
DW_AT_const_value (4)
Newly added
vvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvv
0x0000009a: DW_TAG_variable
DW_AT_specification (0x0000008d "i")
DW_AT_const_value (4)
DW_AT_linkage_name ("_ZN2t2IiE1iIfEE")
```
This patch also drops the `DW_AT_const_value` off of the declaration since we now always have it on the definition. This ensures that the `DWARFParallelLinker` can type-merge class with static members where we couldn't attach the constant on the declaration in some CUs.
We've been using the backtick as our escape character, however that
leads to a weird experience on VS Code, because on most hosts, as soon
as you type the backtick on VS Code, the IDE will introduce another
backtick. As changing the default escape character might be out of
question because other plugins might rely on it, we can instead
introduce an option to change this variable upon lldb-vscode
initialization.
FWIW, my users will be using : instead ot the backtick.
Rename lldb-vscode to lldb-dap. This change is largely mechanical. The
following substitutions cover the majority of the changes in this
commit:
s/VSCODE/DAP/
s/VSCode/DAP/
s/vscode/dap/
s/g_vsc/g_dap/
Discourse RFC:
https://discourse.llvm.org/t/rfc-rename-lldb-vscode-to-lldb-dap/74075/
