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
This patch adds Clang's new (and GCC's old) -Wsuggest-override to the warning flags for the LLVM build. The warning is a stronger form of -Winconsistent-missing-override which warns _everywhere_ that override is missing, not just in places where it's inconsistent within a class.
Some directories in the monorepo need the warning disabled for compatibility's, or sanity's, sake; in particular, libcxx/libcxxabi, and any code implementing or interoperating with googletest, googlemock, or google benchmark (which do not themselves use override). This patch adds -Wno-suggest-override to the relevant CMakeLists.txt's to accomplish this.
Differential Revision: https://reviews.llvm.org/D84126
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.
The sed line in the rules was adding the .d file as a target to the
dependency rules -- to ensure the file gets rebuild when the sources
change. The same thing can be achieved more elegantly with some -M
flags.
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
Reduce sleep and time outs in GDB remote testcases to one default value
for each. Stop passing these values around and always use the default
instead.
Differential revision: https://reviews.llvm.org/D83904
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
This test is hitting https://bugs.python.org/issue22393 which results in
the lit multiprocessing pool deadlocking and the reproducer job timing
out on GreenDragon.
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
Summary:
test_terminate_commands is flaky on LLDB Arm buildbot as well. It was already
being skipped for aarch64. I am going to mark it skipped for Arm too.
Tags: #lldb
Differential Revision: https://reviews.llvm.org/D81978
Remove custom tearDownHooks from GDB Remote tests as we now cleanup
subprocesses unconditionally. This also changes the termination order to
be the reverse of the creation order. I don't think anything is relying
on that right now, but it better fits the setup/teardown paradigm.
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
Several scripts (two copies of use_lldb_suite.py, and an __init__.py) look for use_lldb_suite_root.py by checking parent directories. If for some reason it doesn't exist, it keeps checking parent directories until it finds it.
However, this only breaks when the parent directory is None, but at least on Linux, dirname('/') == '/', so this will never be None.
This changes the lookup to stop if the dirname(lldb_root) is unchanged. This was previously fixed in 67f6d842fa, but only in one copy of this script.
Additionally, this makes the failure mode more visible -- if the root is not found, it complains loudly instead of silently failing, and having later modules that need lldb_root fail.
Differential Revision: https://reviews.llvm.org/D83840
Remove the forkSubprocess method and its bookkeeping.
TestCreateAfterAttach is the only test using the fork method and I'm not
convinced it adds enough to warrant the maintenance. Pavel suggested the
same thing in D83815.
This reverts commit 29aab9b5c7.
It seems on Windows the file name is just always "lldbsuite.test.lldbtest" for
all tests and that breaks pretty much everything. Reverting until we have
a better solution.
It's possible to achieve the same effect by providing multi-step recipe
instead of a single-step recipe where the step happens to contain
multiple commands.
It served a puprose while we were using the test name to provide a name
for the created file. Now that the files are created in memory, we don't
need that.
Summary:
Currently expect_expr will not run the expression if no target is selected. This
patch changes this behavior so that expect_expr will instead fall back to the
dummy target similar to what the `expression` command is doing. This way we
don't have to compile an empty executable to be able to use `expect_expr` (which
is a waste of resources for tests that just test generic type system features).
As a test I modernized the TestTypeOfDeclTypeExpr into a Python test +
expect_expr (as it relied on the dummy target fallback of the expression
command).
Reviewers: labath, JDevlieghere
Reviewed By: labath
Subscribers: abidh
Differential Revision: https://reviews.llvm.org/D83388
Summary:
From what I know we already have the restriction that every test in the test
suite needs to have a unique file name as that's used for generating the unique
build directory for a test. It seems there is also a restriction that every test
case class in the test suite needs to have a unique name as that's used to
generate the unique log file name for the test run.
This changes the log file format to use the basename of the test file instead so
that we only have to keep worrying about the 'unique file name' restriction from
now on.
This came up because I started naming the test classes "TestCase" (as repeating
the file name in the test class seems like redudant information that just makes
renaming tests a pain).
Reviewers: labath, JDevlieghere
Reviewed By: labath
Subscribers: mgorny, abidh
Differential Revision: https://reviews.llvm.org/D83767
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
Jonas Devlieghere