Test runs log some of their output to files inside the LLDB session dir. This
session dir is shared between all tests, so all the tests have to make sure they
choose a unique file name inside that directory. We currently choose by default
`<test-class-name>-<test-method-name>` as the log file name. However, that means
that if not every test class in the test suite has a unique class name, then we
end up with a race condition as two tests will try to write to the same log
file.
I already tried in D83767 changing the format to use the test file basename
instead (which we already require to be unique for some other functionality),
but it seems the code for getting the basename didn't work on Windows.
This patch instead just changes that dotest stores the log files in the build
directory for the current test. We know that directory is unique for this test,
so no need to generate some unique file name now. Also removes all the
environment vars and parameters related to the now unused session dir.
The new log paths now look like this for a failure in 'TestCppOperators`:
```
./lldb-test-build.noindex/lang/cpp/operators/TestCppOperators.test_dwarf/Failure.log
./lldb-test-build.noindex/lang/cpp/operators/TestCppOperators.test_dsym/Failure.log
./lldb-test-build.noindex/lang/cpp/operators/TestCppOperators.test_gmodules/Failure.log
```
Reviewed By: labath
Differential Revision: https://reviews.llvm.org/D92498
Extract remote debugging logic from PlatformMacOSX and move it into
PlatformRemoteMacOSX so it can benefit from all the logic necessary for
remote debugging.
Until now, remote macOS debugging was treated almost identical to local
macOS debugging. By moving in into its own class, we can have it inherit
from PlatformRemoteDarwinDevice and all the functionality it provides,
such as looking at the correct DeviceSupport directory.
rdar://68167374
Differential revision: https://reviews.llvm.org/D92452
We currently reject all templates that have either zero args or that have a
parameter pack without a name. Both cases are actually allowed in C++, so
rejecting them leads to LLDB instead falling back to a dummy 'void' type. This
leads to all kind of errors later on (most notable, variables that have such
template types appear to be missing as we can't have 'void' variables and
inheriting from such a template type will cause Clang to hit some asserts when
finding that the base class is 'void').
This just removes the too strict tests and adds a few tests for this stuff (+
some combinations of these tests with preceding template parameters).
Things that I left for follow-up patches:
* All the possible interactions with template-template arguments which seem like a whole new source of possible bugs.
* Function templates which completely lack sanity checks.
* Variable templates are not implemented.
* Alias templates are not implemented too.
* The rather strange checks that just make sure that the separate list of
template arg names and values always have the same length. I believe those
ought to be asserts, but my current plan is to move both those things into a
single list that can't end up in this inconsistent state.
Reviewed By: JDevlieghere, shafik
Differential Revision: https://reviews.llvm.org/D92425
This reverts commit cf1c774d6ace59c5adc9ab71b31e762c1be695b1.
This change caused several regressions in the gdb test suite - at least
a sample of which was due to line zero instructions making breakpoints
un-lined. I think they're worth investigating/understanding more (&
possibly addressing) before moving forward with this change.
Revert "[FastISel] NFC: Clean up unnecessary bookkeeping"
This reverts commit 3fd39d3694d32efa44242c099e923a7f4d982095.
Revert "[FastISel] NFC: Remove obsolete -fast-isel-sink-local-values option"
This reverts commit a474657e30edccd9e175d92bddeefcfa544751b2.
Revert "Remove static function unused after cf1c774."
This reverts commit dc35368ccf17a7dca0874ace7490cc3836fb063f.
Revert "[lldb] Fix TestThreadStepOut.py after "Flush local value map on every instruction""
This reverts commit 53a14a47ee89dadb8798ca8ed19848f33f4551d5.
This patch carries forward our aim to remove offset field from qRegisterInfo
packets and XML register description. I have created a new function which
returns if offset fields are dynamic meaning client can calculate offset on
its own based on register number sequence and register size. For now this
function only returns true for NativeRegisterContextLinux_arm64 but we can
test this for other architectures and make it standard later.
As a consequence we do not send offset field from lldb-server (arm64 for now)
while other stubs dont have an offset field so it wont effect them for now.
On the client side we have replaced previous offset calculation algorithm
with a new scheme, where we sort all primary registers in increasing
order of remote regnum and then calculate offset incrementally.
This committ also includes a test to verify all of above functionality
on Arm64.
Reviewed By: labath
Differential Revision: https://reviews.llvm.org/D91241
* Un-inline the test.
* Use expect_expr everywhere and also check all involved types.
* Clang-format the test sources.
* Explain what we're actually testing with the 'C' and 'D' templates.
* Split out the non-template-parameter-pack part of the test into its own small test.
Our type formatters/summaries match on the internal type name we generate in LLDB for Clang types.
These names were generated using Clang's default printing policy. However Clang's
default printing policy got tweaked over the last month to make the generated type
names more readable (by for example excluding inline/anonymous namespaces and
removing template arguments that have their default value). This broke the formatter
system where LLDB's matching logic now no longer can format certain types as
the new type names generated by Clang's default printing policy no longer match
the type names that LLDB/the user specified.
I already introduced LLDB's own type printing policy and fixed the inline/anonymous
namespaces in da121fff1184267a405f81a87f7314df2d474e1c (just to get the
test suite passing again).
This patch is restoring the old type printing behaviour where always include the template
arguments in the internal type name (even if they match the default args). This should get
template type formatters/summaries working again in the rare situation where we do
know template default arguments within LLDB. This can only happen when either having
a template that was parsed in the expression parser or when we get type information from a C++ module.
The Clang change that removed defaulted template arguments from Clang's printing policy was
e7f3e2103cdb567dda4fd52f81bf4bc07179f5a8
Reviewed By: labath
Differential Revision: https://reviews.llvm.org/D92311
This patch ovverides GetExpeditedRegisterSet for
NativeRegisterContextLinux_arm64 to send vector granule register in
expedited register set if SVE mode is selected.
Reviewed By: labath
Differential Revision: https://reviews.llvm.org/D82855
The test case isn't using the AST matchers for all checks as there doesn't seem to be support for
matching TemplateTypeParmDecl default arguments. Otherwise this is simply importing the
default arguments.
Also updates several LLDB tests that now as intended omit the default template
arguments of several std templates.
Reviewed By: martong
Differential Revision: https://reviews.llvm.org/D92103
After cf1c774d6ace59c5adc9ab71b31e762c1be695b1, Clang seems to generate code
that is more similar to icc/Clang, so we can use the same line numbers for
all compilers in this test.
Extend TestProcessConnect to cover the scenario fixed by
6c0cd5676e0a0feaf836e0399023a6e21224467b. This replaces
command-process-connect.test which would fail if port 4321
was open.
Add a 'can_connect' parameter to Process plugin initialization, and use
it to filter plugins to these capable of remote connections. This is
used to prevent 'process connect' from picking up a plugin that can only
be used locally, e.g. the legacy FreeBSD plugin.
Differential Revision: https://reviews.llvm.org/D91810
Restore Linux-alike regset names for AVX/MPX registers
as TestLldbGdbServer seems to depend on them. At the same time, fix
TestRegisters to be aware that they are not available on FreeBSD
and NetBSD, at least until we figure out a better way of reporting
unsupported register sets.
Differential Revision: https://reviews.llvm.org/D91923
Fix qRegisterInfo tests to handle Exx error response when querying
registers that are not supported on the platform in question. This
is how FreeBSD and NetBSD platforms reporting missing registers right
now, and there certainly is value from verifying the remaining
registers.
This change fixes the test for FreeBSD but NetBSD has other regressions
that still need to be researched.
Differential Revision: https://reviews.llvm.org/D91922
Translate between abridged and full ftag values in order to expose
the latter in the gdb-remote protocol while the former are used by
FXSAVE/XSAVE... This matches the gdb behavior.
The Shell/Register tests now rely on the new behavior, and therefore
are run on non-Darwin systems only. The Python (API) test relies
on the legacy behavior, and is run on Darwin only.
Differential Revision: https://reviews.llvm.org/D91504
This extends the "memory region" command to
show tagged regions on AArch64 Linux when the MTE
extension is enabled.
(lldb) memory region the_page
[0x0000fffff7ff8000-0x0000fffff7ff9000) rw-
memory tagging: enabled
This is done by adding an optional "flags" field to
the qMemoryRegion packet. The only supported flag is
"mt" but this can be extended.
This "mt" flag is read from /proc/{pid}/smaps on Linux,
other platforms will leave out the "flags" field.
Where this "mt" flag is received "memory region" will
show that it is enabled. If it is not or the target
doesn't support memory tagging, the line is not shown.
(since majority of the time tagging will not be enabled)
Testing is added for the existing /proc/{pid}/maps
parsing and the new smaps parsing.
Minidump parsing has been updated where needed,
though it only uses maps not smaps.
Target specific tests can be run with QEMU and I have
added MTE flags to the existing helper scripts.
Reviewed By: labath
Differential Revision: https://reviews.llvm.org/D87442
We can handle all the types in the expression evaluator now without casting.
On Linux, we have a system header declaration that is still causing issues, so
I'm skipping the test there until I get around to fix this.
Depends on D90490.
The stop command is simple and invokes the new method Trace::StopTracingThread(thread).
On the other hand, the start command works by delegating its implementation to a CommandObject provided by the Trace plugin. This is necessary because each trace plugin needs different options for this command. There's even the chance that a Trace plugin can't support live tracing, but instead supports offline decoding and analysis, which means that "thread trace dump instructions" works but "thread trace start" doest. Because of this and a few other reasons, it's better to have each plugin provide this implementation.
Besides, I'm using the GetSupportedTraceType method introduced in D90490 to quickly infer what's the trace plug-in that works for the current process.
As an implementation note, I moved CommandObjectIterateOverThreads to its header so that I can use it from the IntelPT plugin. Besides, the actual start and stop logic for intel-pt is not part of this diff.
Reviewed By: clayborg
Differential Revision: https://reviews.llvm.org/D90729
init_llgs_test no longer takes an argument
but these two were not updated.
Also fix some mistakes in TestAutoInstallMainExecutable
to get it passing again.
Reviewed By: JDevlieghere, labath
Differential Revision: https://reviews.llvm.org/D91612
LLDB is currently always activating C++ when parsing expressions as LLDB itself
is using C++ features when creating the final AST that will be codegen'd
(specifically, references to variables, namespaces and using declarations are
used).
This is causing problems for users that have variables in non-C++ programs (e.g.
plain C or Objective-C) that have names which are keywords in C++. Expressions
referencing those variables fail to parse as LLDB's Clang parser thinks those
identifiers are C++ keywords and not identifiers that may belong to a
declaration.
We can't just disable C++ in the expression parser for those situations as
replacing the functionality of the injected C++ code isn't trivial. So this
patch is just disabling most keywords that are exclusive to C++ in LLDB's Clang
parser when we are in a non-C++ expression. There are a few keywords we can't
disable for now:
* `using` as that's currently used in some situations to inject variables into the expression function.
* `__null` as that's used by LLDB to define `NULL`/`Nil`/`nil`.
Getting rid of these last two keywords is possible but is a large enough change
that this will be handled in follow up patches.
Note that this only changes the keyword status of those tokens but this patch
does not remove any C++ functionality from the expression parser. The type
system still follows C++ rules and so does the rest of the expression parser.
There is another small change that gives the hardcoded macro definitions in LLDB
a higher precedence than the macros imported from the Objective-C modules. The
reason for this is that the Objective-C modules in LLDB are actually parsed in
Objective-C++ mode and they end up providing the C++ definitions of certain
system macros (like `NULL` being defined as `nullptr`). So we have to move the
LLDB definition forward and surround the definition from the module with an
`#ifdef` to make sure that we use the correct LLDB definition that doesn't
reference C++ keywords. Or to give an example, this is how the expression source
code changes:
Before:
```
#define NULL (nullptr) // injected module definition
#ifndef NULL
#define NULL (__null) // hardcoded LLDB definition
#endif
```
After:
```
#ifndef NULL
#define NULL (__null) // hardcoded LLDB definition
#endif
#ifndef NULL
#define NULL (nullptr) // injected module definition
#endif
```
Fixes rdar://10356912
Reviewed By: shafik
Differential Revision: https://reviews.llvm.org/D82770
"[lldb/DataFormatters] Display null C++ pointers as nullptr" added an assumption
that the member we check for is always a nullptr, but it is actually never
initialized. That causes the test to randomly fail due to the pointer having
some random value that isn't 0.
On x86_64, when you hit a __builtin_debugtrap instruction, you
can continue past this in the debugger. This patch has debugserver
recognize the specific instruction used for __builtin_debugtrap
and advance the pc past it, so that the user can continue execution
once they've hit one of these.
In the patch discussion, we were in agreement that it would be better
to have this knowledge up in lldb instead of depending on each
stub rewriting the pc behind the debugger's back, but that's a
larger scale change for another day.
<rdar://problem/65521634>
Differential revision: https://reviews.llvm.org/D91238
Display null pointer as `nullptr`, `nil` and `NULL` for C++,
Objective-C/Objective-C++ and C respectively. The original motivation
for this patch was to display a null std::string pointer as nullptr
instead of "", but the fix seemed generic enough to be done for all
summary providers.
Differential revision: https://reviews.llvm.org/D77153
When parsing DWARF and laying out bit-fields we don't properly take into account when they are in a union, they will all have a zero offset.
Differential Revision: https://reviews.llvm.org/D91118
When I added TestAbortExitCode I actually planned this to be a generic test for the
exit code functionality on POSIX systems. However due to all the different test setups we
can have I don't think this worked out. Right now the test had to be made so permissive
that it pretty much can't fail.
Just to summarize, we would need to support the following situations:
1. ToT debugserver (on macOS)
2. lldb-server (on other platforms)
3. Any old debugserver version when using the system debugserver (on macOS)
This patch is removing TestAbortExitCode and adds a ToT debugserver specific test
that checks the patch that motivated the whole exit code testing. There is already
an exit-code test for lldb-server from what I can see and 3) is pretty much untestable
as we don't know anything about the system debugserver.
Reviewed By: kastiglione
Differential Revision: https://reviews.llvm.org/D89305
This adds `expect_var_path` to test variable paths so we no longer have to
use `frame var` and find substrs in the command output. The behaviour
is identical with `expect_expr` (and it also uses the same checking backend),
but it instead calls `GetValueForVariablePath` to evaluate the string as a variable
path.
Also rewrites a few of the tests that previously used `frame variable` to use
`expect_var_path`.
Reviewed By: labath
Differential Revision: https://reviews.llvm.org/D90450
Commit 5f12f4ff9078455cad9d4806da01f570553a5bf9 made suppressing inline namespaces
when printing typenames default to true. As we're using the inline namespaces
in LLDB to construct internal type names (which need internal namespaces in them
to, for example, differentiate libc++'s std::__1::string from the std::string
from libstdc++), this broke most of the type formatting logic.
Following discussion in D91193, a change made in D88792 was not quite right.
This restores the message argument, and switches from `expect` to `runCmd`.
Differential Revision: https://reviews.llvm.org/D91206
Those two decorators have identical behaviour. This removes
`not_remote_testsuite_ready` as `skipIfRemote` seems more consistent with the
other decorator names we have
Reviewed By: JDevlieghere
Differential Revision: https://reviews.llvm.org/D89376
Copy the recent improvements from the FreeBSDRemote plugin, notably:
- moving event reporting setup into SetupTrace() helper
- adding more debug info into SIGTRAP handling
- handling user-generated (and unknown) SIGTRAP events
- adding missing error handling to the generic signal handler
- fixing attaching to processes
- switching watchpoint helpers to use llvm::Error
- minor style and formatting changes
This fixes a number of tests, mostly related to fixed attaching.
Differential Revision: https://reviews.llvm.org/D91167
Explicitly copy dbregs to new threads to ensure that watchpoints
are propagated properly. Fixes the test failure due to apparent kernel
race between reporting a new thread and resuming main thread execution
that makes implicit inheritance of dbregs unreliable. By copying them
explicitly, we ensure that the new thread correctly respects watchpoints
that were set after the thread was created but before it was reported.
The code is copied from the NetBSD plugin and modernized to use
llvm::Error.
Differential Revision: https://reviews.llvm.org/D91032
Update the SIGTRAP handler to account for the possibility of SIGTRAP
being generated by the user, i.e. not having any specific debugging
event associated with it, as well as receiving unknown SIGTRAPs. These
instances of SIGTRAP are passed to the regular signal handler.
Differential Revision: https://reviews.llvm.org/D91007
Make category-specifying files visible. There is really no good reason
to keep them hidden, and having them visible increases the chances
that someone will actually spot them.
Differential Revision: https://reviews.llvm.org/D91065
Replace the plethora of ObjC-implied 'skipUnlessDarwin' decorators
with marking tests as 'objc' category (whenever missing), and skip all
ObjC tests on non-Darwin platforms. I have used '.categories' file
wherever it was present already or all (>1) tests were relying on ObjC,
and explicit add_test_categories() where there was only one test.
Differential Revision: https://reviews.llvm.org/D91056
