Summary:
Changed contribution data structure to 64 bit. I added the 32bit and 64bit
accessors to make it explicit where we use 32bit and where we use 64bit. Also to
make sure sure we catch all the cases where this data structure is used.
My host compiler is clang version 15.0.0, which uses -std=c11 by
default. The test asserts that the language is 'c99', and so the test
fails locally.
Update the test to be explicit about compiling with 'c99'.
Reviewed By: Eric
Differential Revision: https://reviews.llvm.org/D139461
On Windows rebuilding the binary isn't enough to unload it
on progrem restart. But the assumption of the test is that on
program re-run LLDB destroys and replaces the old module with
the newly built version. One will have to try hard to evict the
module from the ModuleList (possibly including a call to
`SBDebugger::MemoryPressureDetected`.
See D138724
DynamicLoaderDarwinKernel::SearchForKernelNearPC() searches for a
Darwin kernel mach-o header starting at $pc and working backwards,
stopping on the first memory read error encountered. The kernel,
and the kexts linked in to the kernel, have grown over the years
and the original 32MB scan limit is giving a high chance of failing
to find the kernel if we're in a random kext.
In non-kernel environments, firmware and bare board typically, we
will hit a memory read error on an unmapped page quickly so this
doesn't add a lot of random memory read requests in those environments.
We only check at one megabyte boundaries, so worst case this is 128
reads at the start of a gdb-remote connection. The check for a
memory read error & stopping was a more recent addition (a few years
ago), so I kept the scan region a bit small.
The tests in this patch expose failures of LLDBs expression evaluator
when a standard library is compiled with debug symbols. This is the case
for RelWithDebugInfo builds of llvm-project (with libcxx).
Until these bugs are fixed, we force these tests to use the system's
standard library.
Differential Revision: https://reviews.llvm.org/D139361
Previously we didn't properly trigger the destructor of
the `lldb_private::Module` backing `libfoo.so`. So the newly
rebuilt version wouldn't actually be loaded on a program re-run.
The test expects the fresh module to be loaded.
This relands commit `71f3cac7895ad516ec25438f803ed3c9916c215a`
Fixes LLDB Linux bots and improves TypeSystem flushing for shared libraries.
Differential Revision: https://reviews.llvm.org/D138724
D127284 introduced a new language option which is not benign from modules
perspective. Before this patch lldb would set up the compiler invocation and
later enable incremental processing. Post-D127284 this does not work because
the option causes a module hash mismatch for implicit modules.
In addition, D127284 enables parsing statements on the global scope if
incremental processing is on and thus `syntax_error_for_lldb_to_find` was
rightfully not recognized as a declaration and is considered a statement
which produces a slightly different diagnostic.
Thanks to Michael Buch for the help in understanding this issue. This patch
should appease the lldb bots.
More discussion available at: https://reviews.llvm.org/D127284
This patch adds forward declarations of raw_ostream to those header
files that are relying on the forward declaration of raw_ostream in
llvm/include/llvm/ADT/Optional.h.
I'm planning to move operator<< for Optional<T> and std::optional<T>
from Optional.h to llvm/include/llvm/Support/raw_ostream.h. Once I do
so, we no longer need to forward-declare raw_ostream in Optional.h.
This patch mechanically replaces None with std::nullopt where the
compiler would warn if None were deprecated. The intent is to reduce
the amount of manual work required in migrating from Optional to
std::optional.
This is part of an effort to migrate from llvm::Optional to
std::optional:
https://discourse.llvm.org/t/deprecating-llvm-optional-x-hasvalue-getvalue-getvalueor/63716
This patch mechanically replaces None with std::nullopt where the
compiler would warn if None were deprecated. The intent is to reduce
the amount of manual work required in migrating from Optional to
std::optional.
This is part of an effort to migrate from llvm::Optional to
std::optional:
https://discourse.llvm.org/t/deprecating-llvm-optional-x-hasvalue-getvalue-getvalueor/63716
This was found by clang-tidy bugprone-undelegated-constructor check.
Was there since the very first commit back in 2016.
Reviewed By: clayborg, labath, srhines
Differential Revision: https://reviews.llvm.org/D114111
DWARFExpression::Evaluate will convert DW_OP_addr addresses in
a DWARF expression into load addresses on the expression stack
when there is a StackFrame in the ExecutionContext, this from
a change in 2018 in https://reviews.llvm.org/D46362. At the
time this was handling a case that came up in swift programs,
and is no longer necessary. I generalized this conversion to
a load address when a Target is available in
https://reviews.llvm.org/D137682 to make a test case possible;
this change broke a use case that Ted reported.
This change removes my test case, and removes this conversion
of a DW_OP_addr into a load address in some instances.
Differential Revision: https://reviews.llvm.org/D139226
This doesn't seem to be necessary anymore so remove it to be more consistent with rest of the LLVM projects
that don't use prefix headers.
Differential Revision: https://reviews.llvm.org/D139058
It seems like the license header got mangled somehow, joining multiple
lines together and splitting some lines across multiple ones. That is
causing errors in a license checker I'm using (called REUSE).
This commit restores the license header to the format used by the rest
of the files in the project.
Differential Revision: https://reviews.llvm.org/D138271
**Summary**
This patch addresses #59128, where LLDB would crash when evaluating
importing a type that has been imported before into the same target.
The proposed solution is to clear the scratch AST (and associated
persistent variables, `ClangASTImporter`, etc.) whenever a module that
could've owned one of the stale `TypeSystem`s gets unloaded/destroyed.
Details:
1. The first time we evaluate the expression we import the decl for Foo into the Targets scratch AST
context (lives in m_scratch_type_system_map). During this process we also create a ClangASTImporter
that lives in the ClangPersistentVariables::m_ast_importer_sp. This importer has decl tracking
structures which reference the source AST that the decl got imported from. This importer also gets
re-used for all calls to DeportType (which we use to copy the final decl into the Targets scratch AST).
2. Rebuilding the executable triggers a tear-down of the Module that was backing the ASTContext that
we originally got the Foo decl from (which lived in the Module::m_type_system_map). However, the Target’s scratch AST lives on.
3. Re-running the same expression will now create a new ASTImporterDelegate where the destination TranslationUnitDecl is
the same as the one from step (1).
4. When importing the new Foo decl we first try to find it in the destination DeclContext, which happens to be
the scratch destination TranslationUnitDecl. The `Foo` decl exists in this context since we copied it into
the scratch AST in the first run. The ASTImporter then queries LLDB for the origin of that decl. Using the
same persistent variable ClangASTImporter we claim the decl has an origin in the AST context that got torn
down with the Module. This faulty origin leads to a use-after-free.
**Testing**
- Added API test
Differential Revision: https://reviews.llvm.org/D138724
Currently all callsites already assume the pointer is non-null.
This patch just asserts this assumption.
This is practically enforced by `ModuleList::Append`
which won't add `nullptr`s to `m_modules`.
Differential Revision: https://reviews.llvm.org/D139082
Because Host::RunShellCommand runs commands through $SHELL there is an
opportunity for this to fail spectacularly on systems that use custom
shells with odd behaviors. This patch makes these situations easier to
debug by at least logging the result of the failed xcrun invocation.
It also doesn't run xcrun through a shell any more.
rdar://102389438
Differential Revision: https://reviews.llvm.org/D138060
Allow `dwim-print` to evaluate expressions using the dummy target if no real
target exists.
This adds some parity to `expression`. With this, both of the following work:
```
lldb -o 'expr 1+2'
lldb -o 'dwim-print 1+2'
```
Differential Revision: https://reviews.llvm.org/D138960
`GetNumCompileUnits` has fast execution, and is high firing. Fast and frequent functions are not good candidates for timers. In a recent profile, `GetNumCompileUnits` was called >>10k times with an average duration of 1 microsecond.
Differential Revision: https://reviews.llvm.org/D138878
A previous patch added the ability for us to tell if types were forcefully completed. This patch adds the ability to see which modules have forcefully completed types and aggregates the number of modules with forcefully completed types at the root level.
We add a module specific setting named "debugInfoHadIncompleteTypes" that is a boolean value. We also aggregate the number of modules at the root level that had incomplete debug info with a key named "totalModuleCountWithIncompleteTypes" that is a count of number of modules that had incomplete types.
Differential Revision: https://reviews.llvm.org/D138638
This data formatter should print "No Value" if a variant is unset. It does so by checking if `__index` has a value of `-1`, however it does so by interpreting it as a signed int.
By default, `__index` has type `unsigned int`. When `_LIBCPP_ABI_VARIANT_INDEX_TYPE_OPTIMIZATION` is enabled, the type of `__index` is either `unsigned char`, `unsigned short`, or `unsigned int`, depending on how many fields there are -- as small as possible. For example, when `std::variant` has only a few types, the index type is `unsigned char`, and the npos value will be interpreted by LLDB as `255` when it should be `-1`.
This change does not special case the variant optimization; it just reads the type instead of assuming it's `unsigned int`.
Reviewed By: labath
Differential Revision: https://reviews.llvm.org/D138892
Use LLDB_ENABLE_SWIG instead of SWIG_EXECUTABLE or SWIG_FOUND as the
canonical CMake variable to determine whether we have SWIG available in
LLDB. This is a follow-up to b3c978e850.
This patch adds a formatter for `std::ranges::ref_view<T>`.
It simply holds a `T*`, so all this formatter does is dereference
this pointer and format it as `T` would be.
**Testing**
* Added API tests
Differential Revision: https://reviews.llvm.org/D138558
Implements `dwim-print`, a printing command that chooses the most direct,
efficient, and resilient means of printing a given expression.
DWIM is an acronym for Do What I Mean. From Wikipedia, DWIM is described as:
> attempt to anticipate what users intend to do, correcting trivial errors
> automatically rather than blindly executing users' explicit but
> potentially incorrect input
The `dwim-print` command serves as a single print command for users who don't
yet know, or prefer not to know, the various lldb commands that can be used to
print, and when to use them.
This initial implementation is the base foundation for `dwim-print`. It accepts
no flags, only an expression. If the expression is the name of a variable in
the frame, then effectively `frame variable` is used to get, and print, its
value. Otherwise, printing falls back to using `expression` evaluation. In this
initial version, frame variable paths will be handled with `expression`.
Following this, there are a number of improvements that can be made. Some
improvements include supporting `frame variable` expressions or registers.
To provide transparency, especially as the `dwim-print` command evolves, a new
setting is also introduced: `dwim-print-verbosity`. This setting instructs
`dwim-print` to optionally print a message showing the effective command being
run. For example `dwim-print var.meth()` can print a message such as: "note:
ran `expression var.meth()`".
See https://discourse.llvm.org/t/dwim-print-command/66078 for the proposal and
discussion.
Differential Revision: https://reviews.llvm.org/D138315
This patch makes SWIG itself an auto-detected dependency. This allows us
to look for SWIG once in a centralized place and makes it easier
downstream to detect whether to use the static bindings.
Differential revision: https://reviews.llvm.org/D138879
