Previously we just checked via S regs and were not checking
memory content after pushes.
The vpush test confirms that the fix in https://reviews.llvm.org/D130307
is working.
Memory will only be checked if an "after" state is provided.
Reviewed By: clayborg
Differential Revision: https://reviews.llvm.org/D130468
* Look for files that end width arm/thumb.dat,
meaning we don't try to run, for example, vim swap files.
* Print the name of the test that failed.
Reviewed By: clayborg
Differential Revision: https://reviews.llvm.org/D130467
Also correct the test failed message. It implies that what
it's done is compare the 'before' and 'ater' states from the
test input.
Except that that's the whole point of the test, that the state changes.
It should tell you that it compared the result of the emulation to the
'after'.
Reviewed By: clayborg
Differential Revision: https://reviews.llvm.org/D130464
Since some s and d registers overlap we will error if we find both.
This prevents you overwriting one with the other in a test case.
Reviewed By: clayborg
Differential Revision: https://reviews.llvm.org/D130462
This teaches ProcessElfCore to recognise the MTE tag segments.
https://www.kernel.org/doc/html/latest/arm64/memory-tagging-extension.html#core-dump-support
These segments contain all the tags for a matching memory segment
which will have the same size in virtual address terms. In real terms
it's 2 tags per byte so the data in the segment is much smaller.
Since MTE is the only tag type supported I have hardcoded some
things to those values. We could and should support more formats
as they appear but doing so now would leave code untested until that
happens.
A few things to note:
* /proc/pid/smaps is not in the core file, only the details you have
in "maps". Meaning we mark a region tagged only if it has a tag segment.
* A core file supports memory tagging if it has at least 1 memory
tag segment, there is no other flag we can check to tell if memory
tagging was enabled. (unlike a live process that can support memory
tagging even if there are currently no tagged memory regions)
Tests have been added at the commands level for a core file with
mte and without.
There is a lot of overlap between the "memory tag read" tests here and the unit tests for
MemoryTagManagerAArch64MTE::UnpackTagsFromCoreFileSegment, but I think it's
worth keeping to check ProcessElfCore doesn't cause an assert.
Depends on D129487
Reviewed By: omjavaid
Differential Revision: https://reviews.llvm.org/D129489
Refactor the code responsible for sending the "k" packet and move it
into GDBRemoteCommunicationClient::KillProcess() method. This is part
of refactoring to enable multiprocess support in the client,
and to support using the vKill packet instead.
As part of the refactoring, the following functional changes apply:
- Some redundant logging has been removed, as any failures are returned
via exit_string anyway.
- SetLastStopPacket() is no longer called. It is used only to populate
the thread list, and since the process has just exited and we're
terminating the process instance, there's really no reason to set it.
- On successful kill, exit_string is set to "killed", to clearly
indicate that the process has terminated on our request rather than
on its own.
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.llvm.org/D130340
Make compiler-rt an LLDB test dependency if the corresponding target
exists. Similarly we already have `asan` and `tsan` as optional test
dependencies, but we need the `compiler-rt` target when enabling
compiler-rt trough LLVM_ENABLE_RUNTIMES.
This is the first part of support for reading MTE tags from Linux
core files. The format is documented here:
https://www.kernel.org/doc/html/latest/arm64/memory-tagging-extension.html#core-dump-support
This patch adds a method to unpack from the format the core
file uses, which is different to the one chosen for GDB packets.
MemoryTagManagerAArch64MTE is not tied one OS so another OS
might choose a different format in future. However, infrastructure
to handle that would go untested until then so I've chosen not to
attempt to handle that.
Reviewed By: omjavaid
Differential Revision: https://reviews.llvm.org/D129487
This commit adds a fuzzer for LLDB's expression evaluator.
The fuzzer takes a different approach than the current fuzzers
present, and uses an approach that is currently being used for
clang fuzzers.
Instead of fuzzing the evaluator with randomly mutated
characters, protobufs are used to generate a subset of C++. This
is then converted to valid C++ code and sent to the expression
evaluator. In addition, libprotobuf_mutator is used to mutate
the fuzzer's inputs from valid C++ code to valid C++ code, rather
than mutating from valid code to total nonsense.
Differential revision: https://reviews.llvm.org/D129377
Checking if a path is absolute can be expensive and currently the result is not cached in the FileSpec object. This patch adds caching and also code to clear the cache if the file is modified.
Differential Revision: https://reviews.llvm.org/D130396
The FileSpect APIs allow users to modify instance variables directly by getting a non const reference to the directory and filename instance variables. This makes it impossibly to control all of the times the FileSpec object is modified so we can clear the cache. This patch modifies the APIs of FileSpec so no one can modify the directory or filename directly by adding set accessors and by removing the get accessors that are non const.
Many clients were using FileSpec::GetCString(...) which returned a unique C string from a ConstString'ified version of the result of GetPath() which returned a std::string. This caused many locations to use this convenient function incorrectly and could cause many strings to be added to the constant string pool that didn't need to. Most clients were converted to using FileSpec::GetPath().c_str() when possible. Other clients were modified to use the newly renamed version of this function which returns an actualy ConstString:
ConstString FileSpec::GetPathAsConstString(bool denormalize = true) const;
This avoids the issue where people were getting an already uniqued "const char *" that came from a ConstString only to put the "const char *" back into a "ConstString" object. By returning the ConstString instead of a "const char *" clients can be more efficient with the result.
The patch:
- Removes the non const GetDirectory() and GetFilename() get accessors
- Adds set accessors to replace the above functions: SetDirectory() and SetFilename().
- Adds ClearDirectory() and ClearFilename() to replace usage of the FileSpec::GetDirectory().Clear()/FileSpec::GetFilename().Clear() call sites
- Fixed all incorrect usage of FileSpec::GetCString() to use FileSpec::GetPath().c_str() where appropriate, and updated other call sites that wanted a ConstString to use the newly returned ConstString appropriately and efficiently.
Differential Revision: https://reviews.llvm.org/D130309
Previously you got:
AssertionError: False is not True : Emulation test succeeded.
Which is a bit of a head scratcher. The message is used when
the test fails, not when it succeeds.
DW_OP_skip/DW_OP_bra can move offset to the end of the data, which means that this was the last instruction to execute and the interpreter should terminate.
Reviewed By: labath
Differential Revision: https://reviews.llvm.org/D130285
This patch adds support for evaluating expressions which reference
a captured `this` from within the context of a C++ lambda expression.
Currently LLDB doesn't provide Clang with enough information to
determine that we're inside a lambda expression and are allowed to
access variables on a captured `this`; instead Clang simply fails
to parse the expression.
There are two problems to solve here:
1. Make sure `clang::Sema` doesn't reject the expression due to an
illegal member access.
2. Materialize all the captured variables/member variables required
to evaluate the expression.
To address (1), we currently import the outer structure's AST context
onto `$__lldb_class`, making the `contextClass` and the `NamingClass`
match, a requirement by `clang::Sema::BuildPossibleImplicitMemberExpr`.
To address (2), we inject all captured variables as locals into the
expression source code.
**Testing**
* Added API test
This is required in preparation for the follow-up patch which adds
support for evaluating expressions from within C++ lambdas. In such
cases we need to materialize variables which are not part of the
current frame but instead are ivars on a 'this' pointer of the current
frame.
Using invalidated vector iterator is at best a UB and could crash depending on STL implementation.
Fixing via minimal changes to preserve the existing code style.
Coverity warning 1454828 (scan.coverity.com)
Differential Revision: https://reviews.llvm.org/D130312
Extract a bit of copy/pasted regex filtering logic into a separate
function and simplify it a little bit.
Differential Revision: https://reviews.llvm.org/D130219
Update the process ID after handling fork/vfork to ensure that
the process plugin reports the correct PID immediately.
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.llvm.org/D130037
`IntegerLiteral::Create` operates on integer types. For that reason
when we parse DWARF into an AST, when we encounter a constant
initialized enum member variable, we try to determine the underlying
integer type before creating the `IntegerLiteral`. However, we
currently don't desugar the type and for enum typedefs
`dyn_cast<EnumType>` fails. In debug builds this triggers following
assert:
```
Assertion failed: (type->isIntegerType() && "Illegal type in IntegerLiteral"), function IntegerLiteral, file Expr.cpp, line 892
```
This patch turns the `dyn_cast<EnumType>` into a `getAs<EnumType>`
which `dyn_cast`s the canonical type, allowing us to get to the
underlying integer type.
**Testing**
* API test
* Manual repro is fixed
Differential Revision: https://reviews.llvm.org/D130213
This patch adds support for formatting `std::map::const_iterator`.
It's just a matter of adding `const_` to the existing regex.
**Testing**
* Added test case to existing API tests
Differential Revision: https://reviews.llvm.org/D129962
This reverts commit 5778ada8e5.
The watchpoint tests all stall on aarch64-ubuntu bots. Reverting till I can
get my hands on an system to test this out.
This reverts commit 555ae5b8f5.
Apparently, there's something different about how Linux ARM handles watchpoints,
as all the watchpoint tests seem to stall on the Ubuntu aarch64 bots.
Reverting till I can get my hands on a linux system and see what is
wrong.
That was causing hit counts to be double-counted on x86_64 Linux.
It looks like StopInfoWatchpoint::ShouldStopSynchronous gets called
twice for a give stop on Linux (not on Darwin). I had taken out the
"have I been called already" check when I reworked this part of the
code because it didn't seem necessary. Putting that back in because
it looks like it is on some systems.
We were just emitting "invalid module" w/o saying which module. That's
not particularly helpful.
Differential Revision: https://reviews.llvm.org/D129338
David Spickett