Fix lldb-vscode frame test failure

Previous patch (https://reviews.llvm.org/D126013) added a new "optimized"
attribute to DAP stack frame this caused some tests, like
lldb-vscode/coreFile/TestVSCode

Fix lldb-vscode frame test failure

Previous patch (https://reviews.llvm.org/D126013) added a new "optimized"
attribute to DAP stack frame this caused some tests, like
lldb-vscode/coreFile/TestVSCode_coreFile.py
to fail because the tests explicitly check for all attributes.

To fix the test failure I decided to remove this attribute.

Differential Revision: https://reviews.llvm.org/D126225

show more ...

Show error message for optimized variables

This fixes an issue that optimized variable error message is not shown to end
users in lldb-vscode.

Differential Revision: https://reviews.llvm.org/D126014

Add [opt] suffix to optimized stack frame in lldb-vscode

To help user identify optimized code This diff adds a "[opt]" suffix to
optimized stack frames in lldb-vscode. This provides consistent exper

Add [opt] suffix to optimized stack frame in lldb-vscode

To help user identify optimized code This diff adds a "[opt]" suffix to
optimized stack frames in lldb-vscode. This provides consistent experience
as command line lldb.

It also adds a new "optimized" attribute to DAP stack frame object so that
it is easy to identify from telemetry than parsing trailing "[opt]".

Differential Revision: https://reviews.llvm.org/D126013

show more ...

Add "indexedVariables" to variables with lots of children.

Prior to this fix if we have a really large array or collection class, we would end up always creating all of the child variables for an ar

Add "indexedVariables" to variables with lots of children.

Prior to this fix if we have a really large array or collection class, we would end up always creating all of the child variables for an array or collection class. If the number of children was very high this can cause delays when expanding variables. By adding the "indexedVariables" to variables with lots of children, we can keep good performance in the variables view at all times. This patch will add the "indexedVariables" key/value pair to any "Variable" JSON dictionairies when we have an array of synthetic child provider that will create more than 100 children.

We have to be careful to not call "uint32_t SBValue::GetNumChildren()" on any lldb::SBValue that we use because it can cause a class, struct or union to complete the type in order to be able to properly tell us how many children it has and this can be expensive if you have a lot of variables. By default LLDB won't need to complete a type if we have variables that are classes, structs or unions unless the user expands the variable in the variable view. So we try to only get the GetNumChildren() when we have an array, as this is a cheap operation, or a synthetic child provider, most of which are for showing collections that typically fall into this category. We add a variable reference, which indicates that something can be expanded, when the function "bool SBValue::MightHaveChildren()" is true as this call doesn't need to complete the type in order to return true. This way if no one ever expands class variables, we don't need to complete the type.

Differential Revision: https://reviews.llvm.org/D125347

show more ...

[lldb-vscode] Add presentation hints for scopes

Scopes can have an optional hint for how to present this scope in the UI:
https://microsoft.github.io/debug-adapter-protocol/specification#Types_Scope

[lldb-vscode] Add presentation hints for scopes

Scopes can have an optional hint for how to present this scope in the UI:
https://microsoft.github.io/debug-adapter-protocol/specification#Types_Scope

The IDEs can use the hint to present the data accordingly. For example,
Visual Studio has a separate Registers window, which is populated with the
data from the scope with `presentationHint: "registers"`.

Reviewed By: wallace

Differential Revision: https://reviews.llvm.org/D113400

show more ...

[lldb-vscode] Follow up of D99989 - store some strings more safely

As a follow up of https://reviews.llvm.org/D99989#inline-953343, I'm now
storing std::string instead of char *. I know it might nev

[lldb-vscode] Follow up of D99989 - store some strings more safely

As a follow up of https://reviews.llvm.org/D99989#inline-953343, I'm now
storing std::string instead of char *. I know it might never break as char *,
but if it does, chasing that bug might be dauting.
Besides, I'm also checking of the strings gotten through the SB API are
null or not.

show more ...

[lldb] [gdb-remote server] Introduce new stop reasons for fork and vfork

Introduce three new stop reasons for fork, vfork and vforkdone events.
This includes server support for serializing fork/vfor

[lldb] [gdb-remote server] Introduce new stop reasons for fork and vfork

Introduce three new stop reasons for fork, vfork and vforkdone events.
This includes server support for serializing fork/vfork events into
gdb-remote protocol. The stop infos for the two base events take a pair
of PID and TID for the newly forked process.

Differential Revision: https://reviews.llvm.org/D100196

show more ...

[lldb-vscode] Distinguish shadowed variables in the scopes request

VSCode doesn't render multiple variables with the same name in the variables view. It only renders one of them. This is a situation

[lldb-vscode] Distinguish shadowed variables in the scopes request

VSCode doesn't render multiple variables with the same name in the variables view. It only renders one of them. This is a situation that happens often when there are shadowed variables.
The nodejs debugger solves this by adding a number suffix to the variable, e.g. "x", "x2", "x3" are the different x variables in nested blocks.

In this patch I'm doing something similar, but the suffix is " @ <file_name:line>), e.g. "x @ main.cpp:17", "x @ main.cpp:21". The fallback would be an address if the source and line information is not present, which should be rare.

This fix is only needed for globals and locals. Children of variables don't suffer of this problem.

When there are shadowed variables
{F16182150}

Without shadowed variables
{F16182152}

Modifying these variables through the UI works

Reviewed By: clayborg

Differential Revision: https://reviews.llvm.org/D99989

show more ...

[trace][intel-pt] Implement trace start and trace stop

This implements the interactive trace start and stop methods.

This diff ended up being much larger than I anticipated because, by doing it, I

[trace][intel-pt] Implement trace start and trace stop

This implements the interactive trace start and stop methods.

This diff ended up being much larger than I anticipated because, by doing it, I found that I had implemented in the beginning many things in a non optimal way. In any case, the code is much better now.

There's a lot of boilerplate code due to the gdb-remote protocol, but the main changes are:

- New tracing packets: jLLDBTraceStop, jLLDBTraceStart, jLLDBTraceGetBinaryData. The gdb-remote packet definitions are quite comprehensive.
- Implementation of the "process trace start|stop" and "thread trace start|stop" commands.
- Implementaiton of an API in Trace.h to interact with live traces.
- Created an IntelPTDecoder for live threads, that use the debugger's stop id as checkpoint for its internal cache.
- Added a functionality to stop the process in case "process tracing" is enabled and a new thread can't traced.
- Added tests

I have some ideas to unify the code paths for post mortem and live threads, but I'll do that in another diff.

Differential Revision: https://reviews.llvm.org/D91679

show more ...

[vscode] Improve runInTerminal and support linux

Depends on D93874.

runInTerminal was using --wait-for, but it was some problems because it uses process polling looking for a single instance of the

[vscode] Improve runInTerminal and support linux

Depends on D93874.

runInTerminal was using --wait-for, but it was some problems because it uses process polling looking for a single instance of the debuggee:

- it gets to know of the target late, which renders breakpoints in the main function almost impossible
- polling might fail if there are already other processes with the same name
- polling might also fail on some linux machine, as it's implemented with the ps command, and the ps command's args and output are not standard everywhere

As a better way to implement this so that it works well on Darwin and Linux, I'm using now the following process:

- lldb-vscode notices the runInTerminal, so it spawns lldb-vscode with a special flag --launch-target <target>. This flags tells lldb-vscode to wait to be attached and then it execs the target program. I'm using lldb-vscode itself to do this, because it makes finding the launcher program easier. Also no CMAKE INSTALL scripts are needed.
- Besides this, the debugger creates a temporary FIFO file where the launcher program will write its pid to. That way the debugger will be sure of which program to attach.
- Once attach happend, the debugger creates a second temporary file to notify the launcher program that it has been attached, so that it can then exec. I'm using this instead of using a signal or a similar mechanism because I don't want the launcher program to wait indefinitely to be attached in case the debugger crashed. That would pollute the process list with a lot of hanging processes. Instead, I'm setting a 20 seconds timeout (that's an overkill) and the launcher program seeks in intervals the second tepmorary file.

Some notes:
- I preferred not to use sockets because it requires a lot of code and I only need a pid. It would also require a lot of code when windows support is implemented.
- I didn't add Windows support, as I don't have a windows machine, but adding support for it should be easy, as the FIFO file can be implemented with a named pipe, which is standard on Windows and works pretty much the same way.

The existing test which didn't pass on Linux, now passes.

Differential Revision: https://reviews.llvm.org/D93951

show more ...

[lldb][NFC] Apply performance-faster-string-find (`str.find("X")` -> `str.find('x')`)

Retry of D84974

- Fix a small issue caused by a conflicting name (GetObject) on Windows.
The fix was to rename the internal GetObject function to
GetNextFunction.

Revert "Retry of D84974"

This reverts commit 5b2b4f331d78f326e5e29166bec5ad92c864343d.

This caused a link error in
http://lab.llvm.org:8011/builders/lldb-x64-windows-ninja/builds/18794/steps/build/

Revert "Retry of D84974"

This reverts commit 5b2b4f331d78f326e5e29166bec5ad92c864343d.

This caused a link error in
http://lab.llvm.org:8011/builders/lldb-x64-windows-ninja/builds/18794/steps/build/logs/stdio

show more ...

Retry of D84974

The test is being disabled on Linux, as lldb-vscode has a bug with
--wait-for on LInux.
I'm also fixing some compilation warnings.

Revert de6caf871be79dc7549aebe4e4fb57d52f6ed202 and 51128b670d4f757132e927c4f3dd78d257d37f70 (https://reviews.llvm.org/D84974)

The tests seem to be timing out in all linux bots. Need further analysi

Revert de6caf871be79dc7549aebe4e4fb57d52f6ed202 and 51128b670d4f757132e927c4f3dd78d257d37f70 (https://reviews.llvm.org/D84974)

The tests seem to be timing out in all linux bots. Need further analysis.

Revert "run in terminal"

This reverts commit de6caf871be79dc7549aebe4e4fb57d52f6ed202.

show more ...

run in terminal

Simplify Symbol Status Message to Only Debug Info Size

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 b

Simplify Symbol Status Message to Only Debug Info Size

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

show more ...

Add Debug Info Size to Symbol Status

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}

R

Add Debug Info Size to Symbol Status

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

show more ...

Revert "Add Debug Info Size to Symbol Status"

This reverts commit 986e3af53bfe591e88a1ae4f82ea1cc0a15819a3.

It incorrectly deleted clang/tools/clang-format/git-clang-format

Add Debug Info Size to Symbol Status

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.{F123

Add Debug Info Size to Symbol Status

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

show more ...

[lldb-vscode] Fix TestVSCode_setBreakpoints

It was failing because some module events had empty UUID, and that was not handled correctly.
The diff that added that logic is https://reviews.llvm.org/D

[lldb-vscode] Fix TestVSCode_setBreakpoints

It was failing because some module events had empty UUID, and that was not handled correctly.
The diff that added that logic is https://reviews.llvm.org/D82477

show more ...

Retry ""[lldb-vscode] Fix TestVSCode_module""

Original commit c60216db15132401ff60c08ccef899321f63b6b6.

The test can only run on Darwin because of how it was setup, so I'm
enforcing that.

Summary:

Retry ""[lldb-vscode] Fix TestVSCode_module""

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:

show more ...

Revert "[lldb-vscode] Fix TestVSCode_module"
This reverts commit 881af6eb0030986876d3b80668193e5c3c04a87c.

Revert "[lldb-vscode] Add Compile Unit List to Modules View"
This reverts commit 03ef61033f

Revert "[lldb-vscode] Fix TestVSCode_module"
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.

show more ...

[lldb-vscode] Add Compile Unit List to Modules View

Summary: User can expand and check compile unit list for the modules that have debug info.

Reviewers: wallace, clayborg

Reviewed By: clayborg

S

[lldb-vscode] Add Compile Unit List to Modules View

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

show more ...

[lldb-vscode] Add Support for Module Event

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 re

[lldb-vscode] Add Support for Module Event

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

show more ...