Every override returns true and its return value is never checked. I can't
see how clearing an OptionValue could fail, or what you would
do if it did. The return serves no purpose.
Differential Revision: https://reviews.llvm.org/D84253
Summary:
FormattersContainer stores LLDB's formatters. It's implemented as a templated
map-like data structures that supports any kind of value type and only allows
ConstString and RegularExpression as the key types. The keys are used for
matching type names (e.g., the ConstString key `std::vector` matches the type
with the same name while RegularExpression keys match any type where the
RegularExpression instance matches).
The fact that a single FormattersContainer can only match either by string
comparison or regex matching (depending on the KeyType) causes us to always have
two FormatterContainer instances in all the formatting code. This also leads to
us having every type name matching logic in LLDB twice. For example,
TypeCategory has to implement every method twice (one string matching one, one
regex matching one).
This patch changes FormattersContainer to instead have a single `TypeMatcher`
key that wraps the logic for string-based and regex-based type matching and is
now the only possible KeyType for the FormattersContainer. This means that a
single FormattersContainer can now match types with both regex and string
comparison.
To summarize the changes in this patch:
* Remove all the `*_Impl` methods from `FormattersContainer`
* Instead call the FormatMap functions from `FormattersContainer` with a
`TypeMatcher` type that does the respective matching.
* Replace `ConstString` with `TypeMatcher` in the few places that directly
interact with `FormattersContainer`.
I'm working on some follow up patches that I split up because they deserve their
own review:
* Unify FormatMap and FormattersContainer (they are nearly identical now).
* Delete the duplicated half of all the type matching code that can now use one
interface.
* Propagate TypeMatcher through all the formatter code interfaces instead of
always offering two functions for everything.
There is one ugly design part that I couldn't get rid of yet and that is that we
have to support getting back the string used to construct a `TypeMatcher` later
on. The reason for this is that LLDB only supports referencing existing type
matchers by just typing their respective input string again (without even
supplying if it's a regex or not).
Reviewers: davide, mib
Reviewed By: mib
Subscribers: mgorny, JDevlieghere
Differential Revision: https://reviews.llvm.org/D84151
RecordInterestingDirectory was added to collect dSYM bundles and their
content. For the current working directory we only want the directory to
be part of the VFS, not necessarily its contents. This patch renames the
current method to RecordInterestingDirectoryRecursively and adds a new
one that's not recursive.
Summary:
FormattersContainer currently has an unused `m_name` member. Usually LLDB allows
giving objects names, but for the FormattersContainer it seems excessive. There
are only 4 FormattersContainer variables in LLDB and they are not usually passed
around, so one can always just go up a few frames when debugging to find out
which FormattersContainer you're dealing with.
Reviewers: mib, davide
Reviewed By: mib
Subscribers: JDevlieghere
Differential Revision: https://reviews.llvm.org/D84154
This patch fixes build on lldb-x64-windows-ninja. The error is caused by
use of two leading underscores.
According to MSVC documentation:
In Microsoft C++, identifiers with two leading underscores are reserved
for compiler implementations.
https://docs.microsoft.com/en-us/cpp/cpp/keywords-cpp?view=vs-2019
LinuxPTraceDefines_arm64sve.h defines essential macros for manipulating
AArch64 SVE core dump registers. Add guard for aarch64/Linux hosts where
newer versions of ptrace.h or sigcontext.h might already define SVE macros.
Differential Revision: https://reviews.llvm.org/D83541
file:line:column form that we use to print out locations. Since we
print them this way it makes sense we also accept that form.
Differential Revision: https://reviews.llvm.org/D83975
Use a weak pointer to hold on to the the underlying thread plan in
SBThreadPlan. When the process continues, all the popped ThreadPlans get
discarded, and you can’t reuse them, so you have to create them anew.
Therefore the SBThreadPlan doesn’t need to keep the ThreadPlan alive.
This fixes the cleanup error in TestThreadPlanCommands.py and
TestStepScripted.py caused by the thread plans never being deleted.
Differential revision: https://reviews.llvm.org/D84210
Currently expressions dealing with bit-fields in Objective-C objects is pretty broken. When generating debug-info for Objective-C bit-fields DW_AT_data_bit_offset has a different meaning than it does to C and C++.
When we parse the DWARF we validate bit offsets for C and C++ correctly but not for ObjC. For ObjC in some cases we end up incorrectly flagging an error and we don't generate further bit-fields in the AST.
Later on when we do a name lookup we don't find the ObjCIvarDecl in the ObjCInterfaceDecl in some cases since we never added it and then we don't go to the runtime to obtain the offset.
This will fix how we handle bit-fields for the Objective-C case and add tests to verify this fix but also to documents areas that still don't work and will be addressed in follow-up PRs.
Note: we can never correctly calculate offsets statically because of how Objective-C deals with the fragile base class issue. Which means the runtime may need to shift fields over.
Differential Revision: https://reviews.llvm.org/D83433
The function was fairly complicated and didn't support new bigger
integer sizes. Use llvm function for loading an APInt from memory to
write a unified implementation for all sizes.
Summary:
This patch adds support for AArch64 SVE register infos description and
core file register access.
AArch64 SVE is a an optional extension of Arm v8.3-a architecture. It
has introduced 32 new vector registers Z, 16 predicate P registers and FFR
predicate register. These registers have fixed names but can dynamically
be configured to different size based on underlying OS configuration.
This patch adds register info struct that describes SVE register infos and
also provides RegisterContextPOSIXCore_arm64 routines to access SVE registers.
This patch also introduces a mechanism to configure SVE register sizes and
offsets at startup before exchanging register information across gdb-remote.
TestLinuxCore.py has been updated to include testing of SVE core files.
Reviewers: labath, clayborg, jankratochvil, jasonmolenda, rengolin
Reviewed By: labath
Subscribers: tschuett, kristof.beyls, danielkiss, lldb-commits
Differential Revision: https://reviews.llvm.org/D77047
Summary:
SVE elf note data requires SVE PT macros for reading writing data. Same macros are used by Linux ptrace SVE register access.
This patch makes necessary changes to lldb/source/Plugins/Process/Linux/LinuxPTraceDefines_arm64sve.h in order to make them sysroot independent.
Reviewers: labath, rengolin
Reviewed By: labath
Subscribers: tschuett, lldb-commits, kristof.beyls
Differential Revision: https://reviews.llvm.org/D83541
Summary:
This patch removes dependence of RegisterContextPOSIX_arm64 on register number enums defined in lldb-arm64-register-enums.h.
RegisterContextPOSIX_arm64 makes use of helper functions to access register numbers defined in RegisterInfos_arm64.h via RegisterInfosPOSIX_arm64.
Reviewers: labath
Reviewed By: labath
Subscribers: emaste, kristof.beyls, arphaman, danielkiss, lldb-commits
Differential Revision: https://reviews.llvm.org/D83753
Summary:
When modules reference each other (which happens for example with the different
modules LLDB loads when debugging -gmodules-compiled binaries), just iterating
over the module list once isn't good enough to find all orphans. Any removed
modules in the module list will also clear up the shared pointers they hold to
other modules, so after any module was removed from the list, LLDB should
iterate again and check if any additional modules can no be safely deleted.
This is currently causing that many gmodules tests are not cleaning up all
allocated modules which causes cleanup asserts to fail (right now these asserts
just mark the test as unsupported, but after D83865 the tests will start
failing).
Reviewers: aprantl, clayborg, JDevlieghere
Reviewed By: JDevlieghere
Differential Revision: https://reviews.llvm.org/D84015
The `intrinsics_gen` target exists in the CMake exports since r309389
(see LLVMConfig.cmake.in), hence projects can depend on `intrinsics_gen`
even it they are built separately from LLVM.
Reviewed By: MaskRay, JDevlieghere
Differential Revision: https://reviews.llvm.org/D83454
Summary:
This code (recently responsible for a unaligned access sanitizer
failure) claims that the string table offset zero should result in an
empty string.
I cannot find any mention of this detail in the Microsoft COFF
documentation, and the llvm COFF parser also does not handle offset zero
specially. This code was introduced in 0076e7159, which also does not go
into specifics, citing "various bugfixes".
Given that this is obviously a hack, and does not cause tests to fail, I
think we should just delete it.
Reviewers: amccarth, markmentovai
Subscribers: lldb-commits
Tags: #lldb
Differential Revision: https://reviews.llvm.org/D83881
Summary:
With D81784, lld has started debug info resolving relocations to
garbage-collected symbols as -1 (instead of relocation addend). For an
unaware consumer this generated sequences which seemingly wrap the
address space -- their first entry was 0xfffff, but all other entries
were low numbers.
Lldb stores line sequences concatenated into one large vector, sorted by
the first entry, and searched with std::lower_bound. This resulted in
the low-value entries being placed at the end of the vector, which
utterly confused the lower_bound algorithm, and caused it to not find a
match. (Previously, these sequences would be at the start of the vector,
and normally would contain addresses that are far smaller than any real
address we want to look up, so std::lower_bound was fine.)
This patch makes lldb ignore these kinds of sequences completely. It
does that by changing the construction algorithm from iterating over the
rows (as parsed by llvm), to iterating over the sequences. This is
important because the llvm parsed performs validity checks when
constructing the sequence array, whereas the row array contains raw
data.
Reviewers: JDevlieghere, MaskRay
Differential Revision: https://reviews.llvm.org/D83957
Summary:
Currently the frame recognizers are stored in a global list (the list in the
StackFrameRecognizersManagerImpl singleton to be precise). All commands and
plugins that modify the list are just modifying that global list of recognizers
which is shared by all Target and Debugger instances.
This is clearly against the idea of LLDB being usable as a library and it also
leads to some very obscure errors as now multiple tests are sharing the used
frame recognizers. For example D83400 is currently failing as it reorders some
test_ functions which permanently changes the frame recognizers of all
debuggers/targets. As all frame recognizers are also initialized in a 'once'
guard, it's also impossible to every restore back the original frame recognizers
once they are deleted in a process.
This patch just moves the frame recognizers into the current target. This seems
the way everyone assumes the system works as for example the assert frame
recognizers is using the current target to find the function/so-name to look for
(which only works if the recognizers are stored in the target).
Reviewers: jingham, mib
Reviewed By: jingham, mib
Subscribers: MrHate, JDevlieghere
Differential Revision: https://reviews.llvm.org/D83757
Summary:
When we try to find the executable module for our target we don't check
if we already have an executable module set. This causes that when debugging
a program that dlopens another executable, LLDB will take that other executable
as the new executable of the target (which causes that future launches of the
target will launch the dlopen'd executable instead of the original executable).
This just adds a check that we only set the executable when we haven't already
found one.
Fixes rdar://63443099
Reviewers: jasonmolenda, jingham, teemperor
Reviewed By: jasonmolenda, teemperor
Subscribers: jingham, JDevlieghere
Differential Revision: https://reviews.llvm.org/D80724
Summary:
On macOS 11, the libraries that have been integrated in the system
shared cache are not present on the filesystem anymore. LLDB was
using those files to get access to the symbols of those libraries.
LLDB can get the images from the target process memory though.
This has 2 consequences:
- LLDB cannot load the images before the process starts, reporting
an error if someone tries to break on a system symbol.
- Loading the symbols by downloading the data from the inferior
is super slow. It takes tens of seconds at the start of the
debug session to populate the Module list.
To fix this, we can use the library images LLDB has in its own
mapping of the shared cache. Shared cache images are somewhat
special as their LINKEDIT segment is moved to the end of the cache
and thus the images are not contiguous in memory. All of this can
hidden in ObjectFileMachO.
This patch fixes a number of test failures on macOS 11 due to the
first problem described above and adds some specific unittesting
for the new SharedCache Host utilities.
Reviewers: jasonmolenda, labath
Subscribers: llvm-commits, lldb-commits
Tags: #lldb, #llvm
Differential Revision: https://reviews.llvm.org/D83023
Template specializations are not handled in many of the
TypeSystemClang methods. For example, GetNumChildren does not handle
the TemplateSpecialization type class, so template specializations
always look like empty objects.
This patch just desugars template specializations in the existing
RemoveWrappingTypes desugaring helper.
Differential Revision: https://reviews.llvm.org/D83858
These were found by Clang's new -Wsuggest-override.
This patch doesn't touch any code in unittests/, since much of it intentionally doesn't use override to avoid massive warning spam from -Winconsistent-missing-override due to the use of MOCK_*** macros.
Differential Revision: https://reviews.llvm.org/D83847
Summary:
Certain `NSDate` constructors return a special `NSConstantDate` class which
currently ends up being unformatted as it's not in the list of supported classes
for the NSDate formatter. This patch adds that class to the supported class list
so LLDB produces a summary for it.
One of these special constructors is `[NSDate distantPast]` which returns the
date for `0001-01-01 00:00:00 UTC`. LLDB has a special case for formatting this
date but for some reason we did hardcode the wrong summary string in that
special case. Maybe the summary string was correct back when the code was
written but it isn't correct anymore (`distantPast` isn't actually defined to be
a special date but just some 'a guaranteed temporal boundary.' so maybe someone
changed the value in the last 10 years).
If someone else is wondering why we even have this special case for
`distantPast` but not for the future. The reason seems to be that our date
formatting for really old dates is off by 24 hours. So for example, adding one
second to `distantPast` will cause LLDB to print `0000-12-30 00:00:01 UTC`
(which is 24 hours behind the expected result). So to make our code appear to be
correct it seems we just hardcoded the most common NSDate result from that time
span. I'll replace that logic with a generic solution in a probably more
invasive follow up patch.
I also took the freedom to replace the magic value `-63114076800` with some
constant + documentation. I heard there are some people that don't know from the
top of their head that there are 63114076800 seconds between 1. Jan 0001 and 1.
January 2001 in whatever calendar system NSDate is using.
Reviewers: mib, davide
Reviewed By: mib
Subscribers: JDevlieghere
Differential Revision: https://reviews.llvm.org/D83217
Rather than handling zlib handling manually, use find_package from CMake
to find zlib properly. Use this to normalize the LLVM_ENABLE_ZLIB,
HAVE_ZLIB, HAVE_ZLIB_H. Furthermore, require zlib if LLVM_ENABLE_ZLIB is
set to YES, which requires the distributor to explicitly select whether
zlib is enabled or not. This simplifies the CMake handling and usage in
the rest of the tooling.
This is a reland of abb0075 with all followup changes and fixes that
should address issues that were reported in PR44780.
Differential Revision: https://reviews.llvm.org/D79219
Summary:
This patch extends the ModuleSpec class to include a
DataBufferSP which contains the module data. If this
data is provided, LLDB won't try to hit the filesystem
to create the Module, but use only the data stored in
the ModuleSpec.
Reviewers: labath, espindola
Subscribers: emaste, MaskRay, lldb-commits
Tags: #lldb
Differential Revision: https://reviews.llvm.org/D83512
In synchronous mode, the process connect command and its aliases should
wait for the stop event before claiming the command is complete.
Currently, the stop event is always handled asynchronously by the
debugger.
The implementation takes the same approach as Process::ResumeSynchronous
which hijacks the event and handles it on the current thread. Similarly,
after this patch, the stop event is part of the command return object,
which is the property used by the test case.
Differential revision: https://reviews.llvm.org/D83728
Summary: Just unifying all that copy-pasted code.
Reviewers: JDevlieghere
Reviewed By: JDevlieghere
Differential Revision: https://reviews.llvm.org/D83662
The function's reliance on host types meant that it was needlessly
complicated, and did not handle the newer (wider) types. Rewrite it in
terms of APInt/APFloat functions to save code and improve functionality.
There is a local 'class_language' veriable in DWARFASTParserClang which is named
as if it is related to the 'class_language' member of ParsedDWARFTypeAttributes.
However, it actually only has two possible enum values: 'ObjC' (which means the
current record is a Objective-C class) or 'Unknown' (which covers all other
cases).
This is confusing for the reader and also lead to some strange code where we
have several comparisons against the value "ObjC_plus_plus" (which is always
false).
This replaces the variable with either a const bool variable (if there are
multiple checks for that condition in a function) or a direct call to the
TypeSystemClang utility method for checking if it's a Objective-C
Object/Interface type.
This patch does several things that are all closely related:
- It introduces a new YamlRecorder as a counterpart to the existing
DataRecorder. As the name suggests the former serializes data as yaml
while the latter uses raw texts or bytes.
- It introduces a new MultiProvider base class which can be backed by
either a DataRecorder or a YamlRecorder.
- It reimplements the CommandProvider in terms of the new
MultiProvider.
Finally, it adds unit testing coverage for the MultiProvider, a naive
YamlProvider built on top of the new YamlRecorder and the existing
MutliLoader.
Differential revision: https://reviews.llvm.org/D83441
Summary:
This fixes an override issue by marking a function as const so that the
signature maps to the signature of the function in the base class.
This is the original error:
In file included from /root/llvm/lldb/source/Plugins/Process/Linux/NativeRegisterContextLinux_s390x.cpp:11:
/root/llvm/lldb/source/Plugins/Process/Linux/NativeRegisterContextLinux_s390x.h:79:10: error: 'size_t lldb_private::process_linux::NativeRegisterContextLinux_s390x::GetGPRSize()' marked 'override', but does not override
79 | size_t GetGPRSize() override { return sizeof(m_regs); }
| ^~~~~~~~~~
Subscribers: lldb-commits
Tags: #lldb
Differential Revision: https://reviews.llvm.org/D83580
