VScode now sends a "scopes" DAP request immediately after any expression evaluation.
This scopes request would clear and invalidate any non-scoped expandable variables in g_vsc.variables, causing later "variables" request to return empty result.
The symptom is that any expandable variables in VScode watch window/debug console UI to return empty content.
This diff fixes this issue by only clearing the expandable variables at process continue time. To achieve this, we have to repopulate all scoped variables
during context switch for each "scopes" request without clearing global expandable variables.
So the PR puts the scoped variables into its own locals/globals/registers; and all expandable variables into separate "expandableVariables" list.
Also, instead of using the variable index for "variableReference", it generates a new variableReference id each time as the key of "expandableVariables".
As a further new feature, this PR adds a new "expandablePermanentVariables" which has the lifetime of debug session. Any expandable variables from debug console
are added into this list. This enables users to snapshot expanable old variable in debug console and compare with new variables if desire.
Reviewed By: clayborg
Differential Revision: https://reviews.llvm.org/D105166
LLVM includes this header unconditionally on all platforms
(including Windows), so this define should no longer be necessary.
No behavior change.
Differential Revision: https://reviews.llvm.org/D107338
The comment was originally added in 34769d80d. Then D44526
removed the flag added there (but kept the comment), and then
D66966 reintroduced a .noindex dir (which D68606 and then 33fca97880
moved around a bit).
No behavior change.
Differential Revision: https://reviews.llvm.org/D107341
In some environments this test could fail if start.S has its own DWARF
CompileUnit or similar are included before the DWARF CompileUnit for the
file.
This change makes the test independent of the index of the compile unit,
instead checking the filename.
Reviewed By: herhut, jankratochvil
Differential Revision: https://reviews.llvm.org/D107300
The .cpp file uses SIGNAL_POLLING_UNSUPPORTED to guard the call
to sigaction, so use it in the .h file too. (LLVM also calls
sigaction without a guard on non-Windows.)
No behavior change.
Differential Revision: https://reviews.llvm.org/D107255
Test dependent on pexpect fail randomly with timeouts on Arm/AArch64 Linux
buildbots. I am setting pexpect timeout from 30 to 60.
I will revert this back if this doesnt improve random failures.
This reverts commit fd18f0e84c.
I reverted this change to see its effect on failing GUI tests on LLDB
Arm/AArch64 Linux buildbots. I could not find any evidence against this
particular change so reverting it back.
Differential Revision: https://reviews.llvm.org/D100243
Following tests have been failing randomly on LLDB Arm and AArch64 Linux
builtbots:
TestMultilineNavigation.py
TestMultilineCompletion.py
TestIOHandlerCompletion.py
TestGuiBasic.py
I have increased allocated CPU resources to these bots but it has not
improved situation to an acceptable level. This patch marks them as
skipped on Arm/AArch64 for now.
Change `ThreadPlanStack::PopPlan` and `::DiscardPlan` to not do the following:
1. Move the last plan, leaving a moved `ThreadPlanSP` in the plans vector
2. Operate on the last plan
3. Pop the last plan off the plans vector
This leaves a period of time where the last element in the plans vector has been moved. I am not sure what, if any, guarantees there are when doing this, but it seems like it would/could leave a null `ThreadPlanSP` in the container. There are asserts in place to prevent empty/null `ThreadPlanSP` instances from being pushed on to the stack, and so this could break that invariant during multithreaded access to the thread plan stack.
An open question is whether this use of `std::move` was the result of a measure performance problem.
Differential Revision: https://reviews.llvm.org/D106171
This change makes sure that DwarfUnit does not load a .dwo file until
necessary. I also take advantage of DWARF 5's guarantee that the first
support file is also the primary file to make it possible to create
a compile unit without loading the .dwo file.
Testcases now require Linux as it is needed for -gsplit-dwarf.
Review By: jankratochvil, dblaikie
Differential Revision: https://reviews.llvm.org/D100299
This change makes sure that DwarfUnit does not load a .dwo file until
necessary. I also take advantage of DWARF 5's guarantee that the first
support file is also the primary file to make it possible to create
a compile unit without loading the .dwo file.
Review By: jankratochvil, dblaikie
Differential Revision: https://reviews.llvm.org/D100299
Update ARMGetSupportedArchitectureAtIndex to consider remote macOS
debugging. Currently, it defaults to an iOS triple when IsHost() returns
false. This fixes TestPlatformSDK.py on Apple Silicon.
Differential revision: https://reviews.llvm.org/D107179
Always codesign binaries on macOS. Apple Silicon has stricter
codesigning requirements, for example requiring macCatalyst binaries to
be signed. Ad-hoc sign everything like we do for other Darwin platforms.
This change makes sure that DwarfUnit does not load a .dwo file until
necessary. I also take advantage of DWARF 5's guarantee that the first
support file is also the primary file to make it possible to create
a compile unit without loading the .dwo file.
Review By: jankratochvil, dblaikie
Differential Revision: https://reviews.llvm.org/D100299
The "memory tag read" command will now tell you
when the allocation tag read does not match the logical
tag.
(lldb) memory tag read mte_buf+(8*16) mte_buf+(8*16)+48
Logical tag: 0x9
Allocation tags:
[0xfffff7ff7080, 0xfffff7ff7090): 0x8 (mismatch)
[0xfffff7ff7090, 0xfffff7ff70a0): 0x9
[0xfffff7ff70a0, 0xfffff7ff70b0): 0xa (mismatch)
The logical tag will be taken from the start address
so the end could have a different tag. You could for example
read from ptr_to_array_1 to ptr_to_array_2. Where the latter
is tagged differently to prevent buffer overflow.
The existing command will read 1 granule if you leave
off the end address. So you can also use it as a quick way
to check a single location.
(lldb) memory tag read mte_buf
Logical tag: 0x9
Allocation tags:
[0xfffff7ff7000, 0xfffff7ff7010): 0x0 (mismatch)
This avoids the need for a seperate "memory tag check" command.
Reviewed By: omjavaid
Differential Revision: https://reviews.llvm.org/D106880
The type field is a signed integer.
(https://sourceware.org/gdb/current/onlinedocs/gdb/General-Query-Packets.html)
However it's not packed in the packet in the way
you might think. For example the type -1 should be:
qMemTags:<addr>,<len>:ffffffff
Instead of:
qMemTags:<addr>,<len>:-1
This change makes lldb-server's parsing more strict
and adds more tests to check that we handle negative types
correctly in lldb and lldb-server.
We only support one tag type value at this point,
for AArch64 MTE, which is positive. So this doesn't change
any of those interactions. It just brings us in line with GDB.
Also check that the test target has MTE. Previously
we just checked that we were AArch64 with a toolchain
that supports MTE.
Finally, update the tag type check for QMemTags to use
the same conversion steps that qMemTags now does.
Using static_cast can invoke UB and though we do do a limit
check to avoid this, I think it's clearer with the new method.
Reviewed By: omjavaid
Differential Revision: https://reviews.llvm.org/D104914
This reverts commit fed25ddc1c.
There has been sporadic failures in LLDB AArch64/Arm 32 buildbots since
this commit. I am temporarily reverting it see if it fixes the issue.
Differential Revision: https://reviews.llvm.org/D100243
Renamed language standard from openclcpp to openclcpp10.
Added new std values i.e. '-cl-std=clc++1.0' and
'-cl-std=CLC++1.0'.
Patch by Topotuna (Justas Janickas)!
Differential Revision: https://reviews.llvm.org/D106266
https://reviews.llvm.org/D45592 added a nice feature to be able to specify a breakpoint by a relative path. E.g. passing foo.cpp or bar/foo.cpp or zaz/bar/foo.cpp is fine. However, https://reviews.llvm.org/D68671 by mistake disabled the test that ensured this functionality works. With time, someone made a small mistake and fully broke the functionality.
So, I'm making a very simple fix and the test passes.
Differential Revision: https://reviews.llvm.org/D107126
The only remaining plugin dependency in Mangled is CPlusPlusLanguage which it
uses to extract information from C++ mangled names. The static function
GetDemangledNameWithoutArguments is written specifically for C++, so it
would make sense for this specific functionality to live in a
C++-related plugin. In order to keep this functionality in Mangled
without maintaining this dependency, I added
`Language::GetDemangledFunctionNameWithoutArguments`.
Differential Revision: https://reviews.llvm.org/D105215
This patch adds an environment variable field. This is usually used as
the basic type of a List field. This is needed to create the process
launch form.
Reviewed By: clayborg
Differential Revision: https://reviews.llvm.org/D106999
This patch adds a Create Target form for the LLDB GUI. Additionally, an
Arch Field was introduced to input an arch and the file and directory
fields now have a required property.
Reviewed By: clayborg
Differential Revision: https://reviews.llvm.org/D106192
If we succeed at gathering global variables for a compile
unit, there is no need to fallback to generating a manual index.
Reviewed By: jankratochvil
Differential Revision: https://reviews.llvm.org/D106355
In the latest Linux kernels synchronous tag faults
include the tag bits in their address.
This change adds logical and allocation tags to the
description of synchronous tag faults.
(asynchronous faults have no address)
Process 1626 stopped
* thread #1, name = 'a.out', stop reason = signal SIGSEGV: sync tag check fault (fault address: 0x900fffff7ff9010 logical tag: 0x9 allocation tag: 0x0)
This extends the existing description and will
show as much as it can on the rare occasion something
fails.
This change supports AArch64 MTE only but other
architectures could be added by extending the
switch at the start of AnnotateSyncTagCheckFault.
The rest of the function is generic code.
Tests have been added for synchronous and asynchronous
MTE faults.
Reviewed By: omjavaid
Differential Revision: https://reviews.llvm.org/D105178
This diff introduces Hierarchical Trace Representation (HTR) and creates the `thread trace export ctf -f <filename> -t <thread_id>` command to export an Intel PT trace's HTR to Chrome Trace Format (CTF) for visualization.
See `lldb/docs/htr.rst` for context/documentation on HTR.
**Overview of Changes**
- Add HTR documentation (see `lldb/docs/htr.rst`)
- Add HTR structures (layer, block, block metadata)
- Implement "Basic Super Block" HTR pass
- Add 'thread trace export ctf' command to export the HTR of an Intel PT
trace to Chrome Trace Format (CTF)
As this diff is the first iteration of HTR and trace visualization, future diffs will build on this work by generalizing the internal design of HTR and implementing new HTR passes that provide better trace summarization/visualization.
See attached video for an example of Intel PT trace visualization:
{F17851042}
Original Author: jj10306
Submitted by: wallace
Reviewed By: wallace, clayborg
Differential Revision: https://reviews.llvm.org/D105741
This diff introduces Hierarchical Trace Representation (HTR) and creates the `thread trace export ctf -f <filename> -t <thread_id>` command to export an Intel PT trace's HTR to Chrome Trace Format (CTF) for visualization.
See `lldb/docs/htr.rst` for context/documentation on HTR.
**Overview of Changes**
- Add HTR documentation (see `lldb/docs/htr.rst`)
- Add HTR structures (layer, block, block metadata)
- Implement "Basic Super Block" HTR pass
- Add 'thread trace export ctf' command to export the HTR of an Intel PT
trace to Chrome Trace Format (CTF)
As this diff is the first iteration of HTR and trace visualization, future diffs will build on this work by generalizing the internal design of HTR and implementing new HTR passes that provide better trace summarization/visualization.
See attached video for an example of Intel PT trace visualization:
{F17851042}
Original Author: jj10306
Submitted by: wallace
Reviewed By: wallace, clayborg
Differential Revision: https://reviews.llvm.org/D105741
The default mode of "memory tag write" is to calculate the
range from the start address and the number of tags given.
(just like "memory write" does)
(lldb) memory tag write mte_buf 1 2
(lldb) memory tag read mte_buf mte_buf+48
Logical tag: 0x0
Allocation tags:
[0xfffff7ff9000, 0xfffff7ff9010): 0x1
[0xfffff7ff9010, 0xfffff7ff9020): 0x2
[0xfffff7ff9020, 0xfffff7ff9030): 0x0
This new option allows you to set an end address and have
the tags repeat until that point.
(lldb) memory tag write mte_buf 1 2 --end-addr mte_buf+64
(lldb) memory tag read mte_buf mte_buf+80
Logical tag: 0x0
Allocation tags:
[0xfffff7ff9000, 0xfffff7ff9010): 0x1
[0xfffff7ff9010, 0xfffff7ff9020): 0x2
[0xfffff7ff9020, 0xfffff7ff9030): 0x1
[0xfffff7ff9030, 0xfffff7ff9040): 0x2
[0xfffff7ff9040, 0xfffff7ff9050): 0x0
This is implemented using the QMemTags packet previously
added. We skip validating the number of tags in lldb and send
them on to lldb-server, which repeats them as needed.
Apart from the number of tags, all the other client side checks
remain. Tag values, memory range must be tagged, etc.
Reviewed By: omjavaid
Differential Revision: https://reviews.llvm.org/D105183
TestGuiBasicDebug.py randomly fails due to timeouts sending out false
negatives on LLDB Arm and AArch64 Linux buildbots. I havnt found a
reliable wayy to set pexpect timeout for this test to pass regularly.
Skipping it on Arm and AArch64 Linux to silence buildbot failures.
This adds a new command for writing memory tags.
It is based on the existing "memory write" command.
Syntax: memory tag write <address-expression> <value> [<value> [...]]
(where "value" is a tag value)
(lldb) memory tag write mte_buf 1 2
(lldb) memory tag read mte_buf mte_buf+32
Logical tag: 0x0
Allocation tags:
[0xfffff7ff9000, 0xfffff7ff9010): 0x1
[0xfffff7ff9010, 0xfffff7ff9020): 0x2
The range you are writing to will be calculated by
aligning the address down to a granule boundary then
adding as many granules as there are tags.
(a repeating mode with an end address will be in a follow
up patch)
This is why "memory tag write" uses MakeTaggedRange but has
some extra steps to get this specific behaviour.
The command does all the usual argument validation:
* Address must evaluate
* You must supply at least one tag value
(though lldb-server would just treat that as a nop anyway)
* Those tag values must be valid for your tagging scheme
(e.g. for MTE the value must be > 0 and < 0xf)
* The calculated range must be memory tagged
That last error will show you the final range, not just
the start address you gave the command.
(lldb) memory tag write mte_buf_2+page_size-16 6
(lldb) memory tag write mte_buf_2+page_size-16 6 7
error: Address range 0xfffff7ffaff0:0xfffff7ffb010 is not in a memory tagged region
(note that we do not check if the region is writeable
since lldb can write to it anyway)
The read and write tag tests have been merged into
a single set of "tag access" tests as their test programs would
have been almost identical.
(also I have renamed some of the buffers to better
show what each one is used for)
Reviewed By: omjavaid
Differential Revision: https://reviews.llvm.org/D105182
The old code incorrectly calculated the start position for the search
for the third (and subsequent) instance of a particular substitution
pattern (e.g. %1).
I also added a few test cases for this parsing covering this failure.
Jeffrey Tan