Let's just return a std::string to make this safe. formatv seemed overkill for formatting
the return values as they all just append an integer value to a constant string.
Reviewed By: labath
Differential Revision: https://reviews.llvm.org/D84505
We saw a crash recently (rdar://problem/65276489) that looks related to an invalid ValueObjectSP in a summary providers in Cocoa.cpp e.g. NSBundleSummaryProvider(...).
This adds checks before we use them usually by calling NSStringSummaryProvider.
Differential Revision: https://reviews.llvm.org/D84272
Most process plugins (if not all) don't set hardware index for breakpoints. They even
are not able to determine this index.
This patch makes StoppointLocation::IsHardware pure virtual and lets BreakpointSite
override it using more accurate BreakpointSite::Type.
It also adds assertions to be sure that a breakpoint site is hardware when this is required.
Differential Revision: https://reviews.llvm.org/D84257
Summary:
This commit is somewhat NFC-ish today as the environment of triples
is not considered when comparing s if one of them is
not set (I plan to change that).
We have made simulator triples unambiguous these days, but the
simulator platforms still advertise triples without the
environment. This wasn't an issue when the sims ran only on
a very different architecure than the real device, but this
has changed with Apple Silicon.
This patch simplifies the way GetSupportedArchitectureAtIndex
is implemented for the sim platforms and adds the environment.
It also trivially adds support for Apple Silicon to those
platforms.
Reviewers: aprantl
Subscribers: lldb-commits
Summary:
This effectively reverts r188124, which added code to handle
(DW_AT_)declarations of structures with some kinds of children as
definitions. The commit message claims this is a workaround for some
kind of debug info produced by gcc. However, it does not go into
specifics, so it's hard to reproduce or verify that this is indeed still a
problem.
Having this code is definitely a problem though, because it mistakenly
declares incomplete dwarf declarations to be complete. Both clang (with
-flimit-debug-info) and gcc (by default) generate DW_AT_declarations of
structs with children. This happens when full debug info for a class is
not emitted in a given compile unit (e.g. because of vtable homing), but
the class has inline methods which are used in the given compile unit.
In that case, the compilers emit a DW_AT_declaration of a class, but
add a DW_TAG_subprogram child to it to describe the inlined instance of
the method.
Even though the class tag has some children, it definitely does not
contain enough information to construct a full class definition (most
notably, it lacks any members). Keeping the class as incomplete allows
us to search for a real definition in other modules, helping the
-flimit-debug-info flow. And in case the definition is not found we can
display a error message saying that, instead of just showing an empty
struct.
Reviewers: clayborg, aprantl, JDevlieghere, shafik
Subscribers: lldb-commits
Tags: #lldb
Differential Revision: https://reviews.llvm.org/D83302
Summary:
The resolver addresses stored in the dyld trie are relative to the base
of the __TEXT segment. This is usually 0 in a dylib, so this was never
noticed, but it is not 0 for most dylibs integrated in the shared cache.
As we started using the shared cache images recently as symbol source,
this causes LLDB to fail to resolve symbols which go through a runtime
resolver.
Reviewers: jasonmolenda, jingham
Subscribers: lldb-commits
Tags: #lldb
Differential Revision: https://reviews.llvm.org/D84083
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
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
This patch has no effect for C and C++. In more dynamic languages,
such as Objective-C and Swift GetByteSize() needs to call into the
language runtime, so it's important to pass one in where possible. My
primary motivation for this is some work I'm doing on the Swift
branch, however, it looks like we are also seeing warnings in
Objective-C that this may resolve. Everything in the SymbolFile
hierarchy still passes in nullptrs, because we don't have an execution
context in SymbolFile, since SymbolFile transcends processes.
Differential Revision: https://reviews.llvm.org/D84267
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.
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
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
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
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
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.
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
Change the code the use the version which accepts a memory buffer,
instead of the one taking a file name.
This ensures we are not loading the file into memory twice
(ObjectFilePECOFF also loads a copy), reducing our memory footprint, as
well as enabling additional goodies in the future, like being able to
open files which don't exist on disk (D83512).
NativeProcessELF::GetELFImageInfoAddress<...>() is declared in NativeProcessELF.h, but only defined in NativeProcessELF.cpp. Via some optimized builds (e.g. thinlto), this instantiation may be removed when it is used in a different TU (NativeProcessELFTest.cpp).
Summary:
DWARF-parsing methods in SymbolFileDWARF which update module state
typically take the module lock. ParseCallEdgesInFunction doesn't do
this, but higher-level locking within lldb::Function (which owns the
storage for parsed call edges) is necessary.
The lack of locking could explain some as-of-yet unreproducible crashes
which occur in Function::GetTailCallingEdges(). In these crashes, the
`m_call_edges` vector is non-empty but contains a nullptr, which
shouldn't be possible. (If this vector is non-empty, it _must_ contain a
non-null unique_ptr.)
This may address rdar://55622443 and rdar://65119458.
Reviewers: jasonmolenda, friss, jingham
Subscribers: aprantl, lldb-commits
Tags: #lldb
Differential Revision: https://reviews.llvm.org/D83359
Summary:
This patch adds some cosmetic changes to LLDB AArch64 register infos macros in order to use them in SVE register infos struct in follow up patches.
This patch initially added invalidate lists to register infos struct but that is no longer needed and problem disappeared after updating qemu testing environment.
old headline comments for reference:
AArch64 reigster X and V registers are primary GPR and vector registers respectively. If these registers are modified their corresponding children w regs or s/d regs should be invalidated. Specially when a register write fails it is important that failure gets reflected to all the registers which draw their value from a particular value register.
Reviewers: labath, rengolin
Reviewed By: labath
Subscribers: tschuett, kristof.beyls, danielkiss, lldb-commits
Differential Revision: https://reviews.llvm.org/D77045
Summary:
This patch aims to combine similar arm64 register set definitions defined in NativeRegisterContextLinux_arm64 and RegisterContextPOSIX_arm64.
I have implemented a register set interface out of RegisterInfoInterface class and moved arm64 register sets into RegisterInfosPOSIX_arm64 which is similar to Utility/RegisterContextLinux_* implemented by various other targets. This will help in managing register sets of new ARM64 architecture features in one place.
Built and tested on x86_64-linux-gnu, aarch64-linux-gnu and arm-linux-gnueabihf targets.
Reviewers: labath
Reviewed By: labath
Subscribers: mhorne, emaste, kristof.beyls, atanasyan, danielkiss, lldb-commits
Differential Revision: https://reviews.llvm.org/D80105
Summary:
Unify the code for requiring a complete type and move it into a single
place. The only functional change is that the "cannot start a definition
of an incomplete type" is upgrated from a runtime error/warning to an
lldbassert. An plain assert might also be fine, since (AFAICT) this can
only happen in case of a programmer error.
Reviewers: teemperor, aprantl, shafik
Subscribers: lldb-commits
Tags: #lldb
Differential Revision: https://reviews.llvm.org/D83199
Summary:
When printing an NSDate (for example with `NSLog` or `po`) the seconds value is
always rounded down. LLDB's own formatter however isn't following that behaviour
which leads to situations where the formatted result is sometimes one second
off. For example:
```
(lldb) p [NSDate dateWithTimeIntervalSince1970:0.1]
(__NSTaggedDate *) $1 = [...] 1970-01-01 00:00:01 UTC
(lldb) po [NSDate dateWithTimeIntervalSince1970:0.1]
1970-01-01 00:00:00 +0000
(lldb) p [NSDate dateWithTimeIntervalSince1970:0.6]
(__NSTaggedDate *) $4 =[...] 1970-01-01 00:00:01 UTC
(lldb) po [NSDate dateWithTimeIntervalSince1970:0.6]
1970-01-01 00:00:00 +0000
```
This patch just always rounds down the seconds value we get from the NSDate
object.
Fixes rdar://65084800
Reviewers: mib, davide
Reviewed By: mib
Subscribers: JDevlieghere
Differential Revision: https://reviews.llvm.org/D83221
With -flimit-debug-info, we can have a definition of a class, but no
definition for some of its members. This extends the same logic we were
using for incomplete base classes to cover incomplete members too.
Test forward-declarations.s is removed as it is no longer applicable --
we don't warn anymore when encountering incomplete members as they could
be completed elsewhere. New checks added to TestLimitDebugInfo cover the
handling of incomplete members more thoroughly.
In general there is no way to get to the ASTContext from most AST nodes
(Decls are one of the exception). This will be a problem when implementing
the rest of APValue::dump since we need the ASTContext to dump some kinds of
APValues.
The ASTContext* in ASTDumper and TextNodeDumper is not always non-null.
This is because we still want to be able to use the various dump() functions
in a debugger.
No functional changes intended.
Reverted in fcf4d5e449 since a few dump()
functions in lldb where missed.
The passthrough DiagnosticConsumer is an implementation detail of
ClangDiagnosticManagerAdapter and we can just hide it behind the normal
DiagnosticConsumer interface that ClangDiagnosticManagerAdapter is supposed
to implement.
On macOS 11 (and other aligned OSs), the shared cache method
lists get an additional optimization which removes one level
of indirection to get to the selector.
This patch supports this new optimization. Both codepaths are
covered byt the existing Objective-C tests.
On macOS 11 (and other aligned Apple OSs), the Objective-C runtime
has a new optimization which saves memory by making the method
lists smaller.
This patch adds support for this new method list encoding (while
also keeping backward compatibility). This is implicitely covered
by some existing Objective-C tests.
This reverts commit 0da0437b2a to unbreak
the following tests:
lldb-api.tools/lldb-server.TestAppleSimulatorOSType.py
lldb-api.tools/lldb-server.TestGdbRemoteAttach.py
lldb-api.tools/lldb-server.TestGdbRemoteProcessInfo.py
lldb-api.tools/lldb-server.TestGdbRemoteRegisterState.py
lldb-api.tools/lldb-server.TestGdbRemoteThreadsInStopReply.py
lldb-api.tools/lldb-server.TestLldbGdbServer.py
The formatter was requesting an unsigned integer from the ValueObject,
but CFAbsoluteTime is a signed double, so in the NSDate test the formatter
actually just printed the 'error value' date which is the Cocoa epoch. This
started failing after the recent Scalar changes.
This patch just changes the logic to use a signed value which fits to the data
we try to read and avoids this issue.
Summary:
This patch adds support for evaluation of expressions referring to types
which were compiled in -flimit-debug-info (a.k.a -fno-standalone-debug)
in clang. In this mode it's possible that the debug information needed
to fully describe a c++ type is not present in a single shared library
-- for example debug info for a base class or a member of a type can
only be found in another shared library. This situation is not
currently handled well within lldb as we are limited to searching within
a single shared library (lldb_private::Module) when searching for the
definition of these types.
The way that this patch gets around this limitation is by doing the
search at a later stage -- during the construction of the expression ast
context. This works by having the parser (currently SymbolFileDWARF, but
a similar approach is probably needed for PDBs too) mark a type as
"forcefully completed". What this means is that the parser has marked
the type as "complete" in the module ast context (as this is necessary
to e.g. derive classes from it), but its definition is not really there.
This is done via a new field on the ClangASTMetadata struct.
Later, when we are importing such a type into the expression ast, we
check this flag. If the flag is set, we try to find a better definition
for the type in other shared libraries. We do this by initiating a
new lookup for the "forcefully completed" classes, which then imports the
type from a module with a full definition.
This patch only implements this handling for base classes, but other
cases (members, array element types, etc.). The changes for that should
be fairly simple and mostly revolve around marking these types as
"forcefully completed" at an approriate time -- the importing logic is
generic already.
Another aspect, which is also not handled by this patch is viewing these
types via the "frame variable" command. This does not use the AST
importer and so it will need to handle these types on its own -- that
will be the subject of another patch.
Differential Revision: https://reviews.llvm.org/D81561
Condition `omit_empty_base_classes` is checked both in an outer and
in an inner `if` statement in `TypeSystemClang::GetNumBaseClasses()`.
This patch removes the redundant inner check.
The issue was found using `clang-tidy` check under review
`misc-redundant-condition`. See https://reviews.llvm.org/D81272.
Differential Revision: https://reviews.llvm.org/D82559
Condition `auto_advance_pc` is checked both in an outer and in an
inner `if` statement in `EmulateInstructionARM::EvaluateInstruction()`,
`EmulateInstructionARM64::EvaluateInstruction()` and
`EmulateInstructionPPC64::EvaluateInstruction()`. This patch removes the
redundant inner check.
The issue was found using `clang-tidy` check under review
`misc-redundant-condition`. See https://reviews.llvm.org/D81272.
Differential Revision: https://reviews.llvm.org/D82558
debugserver and lldb
This patch improves the heuristics for correctly identifying simulator binaries on Darwin and adds support for simulators running on Apple Silicon.
rdar://problem/64046344
Differential Revision: https://reviews.llvm.org/D82616
Summary:
The ClangASTSource has a lock that globally disables all lookups into the
external AST source when we explicitly "guarded" copy a type. It's not used for
anything else, so importing declarations or importing types that are
dependencies of a declaration actually won't activate that lock. The lookups it
is supposed to prevent also don't actually happen in our test suite. The check
in `ClangExpressionDeclMap::FindExternalVisibleDecls` is never executed and the
check in the `ClangASTSource::FindExternalVisibleDeclsByName` is only ever
reached by the `Import-std-module` tests (which explicitly do a lookup into the
expression context on purpose).
This lock was added in 6abfabff61 as a replacement
for a list of types we already looked up which appeared to be an optimisation
strategy. I assume back then this lock had a purpose but these days the
ASTImporter and LLDB seem to be smart enough to avoid whatever lookups this
tried to prevent.
I would say we remove it from LLDB. The main reason is that it blocks D81561
(which explicitly does a specific lookup to resolve placeholder types produced
by `-flimit-debug-info`) but it's semantics are also very confusing. The naming
implies it's a flag to indicate when we import something at the moment which is
practically never true as described above. Also the fact that it makes our
ExternalASTSource alternate between doing lookups into the debug info and
pretending it doesn't know any external decls could really break our lookup in
some weird way if Clang decides to cache a fake empty lookup result that was
generated while the lock was active.
Reviewers: labath, shafik, JDevlieghere, aprantl
Reviewed By: labath, JDevlieghere, aprantl
Subscribers: aprantl, abidh
Differential Revision: https://reviews.llvm.org/D81749
Summary:
This fixes a bug in the logic for choosing the unwind plan. Based on the
comment in UnwindAssembly-x86, the intention was that a plan which
describes the function epilogue correctly does not need to be augmented
(and it should be used directly). However, the way this was implemented
(by returning false) meant that the higher level code
(FuncUnwinders::GetEHFrameAugmentedUnwindPlan) interpreted this as a
failure to produce _any_ plan and proceeded with other fallback options.
The fallback usually chosed for "asynchronous" plans was the
"instruction emulation" plan, which tended to fall over on certain
functions with multiple epilogues (that's a separate bug).
This patch simply changes the function to return true, which signals the
caller that the unmodified plan is ready to be used.
The attached test case demonstrates the case where we would previously
fall back to the instruction emulation plan, and unwind incorrectly --
the test asserts that the "augmented" eh_frame plan is used, and that
the unwind is correct.
Reviewers: jasonmolenda, jankratochvil
Subscribers: davide, echristo, lldb-commits
Tags: #lldb
Differential Revision: https://reviews.llvm.org/D82378
This patch takes the IO redirection logic from ScriptInterpreterPython
and moves it into the interpreter library so that it can be used by
other script interpreters. I've turned it into a RAII object so that we
don't have to worry about cleaning up in the calling code.
Differential revision: https://reviews.llvm.org/D82396
Summary:
When evaluating an expression referencing a constexpr static member variable, an
error is issued because the PDB does not specify a symbol with an address that
can be relocated against.
Rather than attempt to resolve the variable's value within the IR execution, the
values of all constants can be looked up and incorporated into the AST of the
record type as a literal, mirroring the original compiler AST.
This change applies to DIA and native PDB loaders.
Patch By: jackoalan
Reviewers: aleksandr.urakov, jasonmolenda, zturner, jdoerfert, teemperor
Reviewed By: aleksandr.urakov
Subscribers: sstefan1, lldb-commits, llvm-commits, #lldb
Tags: #lldb, #llvm
Differential Revision: https://reviews.llvm.org/D82160
Translated processes talk with a different debugserver, shipped with
macOS 11. This patch detects whether a process is translated and
attaches to the correct debugserver implementation.
It's the first patch of a series. Tested on the lldb test suite.
Differential Revision: https://reviews.llvm.org/D82491
Add support for changing the stdout and stderr file in Lua's I/O library
and hook it up with the debugger's output and error file respectively
for the interactive Lua interpreter.
https://reviews.llvm.org/D82273
This patch contains:
- Support in LLVM CodeGen for bfloat16 types for ld2/3/4 and st2/3/4.
- New bfloat16 ACLE builtins for svld(2|3|4)[_vnum] and svst(2|3|4)[_vnum]
Reviewers: stuij, efriedma, c-rhodes, fpetrogalli
Reviewed By: fpetrogalli
Tags: #clang, #lldb, #llvm
Differential Revision: https://reviews.llvm.org/D82187
Move the part of the code which is responsible for finding a complete
definition of the type into a separate function (FindCompleteType). This
is split off from D81561, as it's a generally useful cleanup.
No functional change.
Add a way to quit the interactive script interpreter from a shell tests.
Currently, the only way (that I know) to exit the interactive Lua
interpreter is to send a EOF with CTRL-D. I noticed that the embedded
Python script interpreter accepts quit (while the regular python
interpreter doesn't). I've added a special case to the Lua interpreter
to do the same.
Differential revision: https://reviews.llvm.org/D82272
Summary:
LLVM is using its own isPrint/isSpace implementation that doesn't change depending on the current locale. LLDB should do the same
to prevent that internal logic changes depending on the set locale.
Reviewers: JDevlieghere, labath, mib, totally_not_teemperor
Reviewed By: JDevlieghere
Differential Revision: https://reviews.llvm.org/D82175
Summary:
Since commit 7b3ef05a37 the Objective-C++ plugin is dead code.
That commit added Objective-C++ to the list of languages for which `Language::LanguageIsCPlusPlus`
returns true. As the C++ language plugin also uses that method to figure out if it is responsible for a
given language, the C++ plugin since then also became the plugin that we found when looking for
a language plugin for Objective-C++. The only real fallout from that is that the source highlighting
for Objective-C++ files never worked as we always found the C++ plugin which refuses to highlight
files with Objective-C++ extensions.
This patch just adds a special exception for Objective-C++ to the list of languages that are governed
by the C++ plugin. Also adds a test that makes sure that we find the right plugin for all C language
types and that the highlighting for `.mm` (Objective-C++) and `.m` (Objective-C) files works.
I didn't revert 7b3ef05a37 as it does make sense to return
true for Objective-C++ from `Language::LanguageIsCPlusPlus` (e.g., we currently check if we care about
ODR violations by doing `if (Language::LanguageIsCPlusPlus(...))` and this should also work for
Objective-C++).
Fixes rdar://64420183
Reviewers: aprantl
Reviewed By: aprantl
Subscribers: mgorny, abidh, JDevlieghere
Differential Revision: https://reviews.llvm.org/D82109
and delete a bunch (but not all) redundant code. If you compare the remaining implementations of Platform*Simulator.cpp, there is still an obvious leftover cleanup task.
Specifically, this patch
- removes SDK initialization from dotest (there is equivalent but more
complete code in Makefile.rules)
- make Platform*Simulator inherit the generic implementation of
PlatformAppleSimulator (more can be done here)
- simplify the platform logic in Makefile.rules
- replace the custom SDK finding logic in Platform*Simulator with XcodeSDK
- adds a test for each supported simulator
Differential Revision: https://reviews.llvm.org/D81980
Summary:
This patch aims to remove multiple copies of GetByteOrder() and ConvertRegisterKindToRegisterNumber used in various versions of RegisterContextPOSIX_*.
Both register implementations are move to RegisterContext class which is parent of RegisterContextPOSIX_* classes.
Built and tested on x86_64-linux-gnu, aarch64-linux-gnu and arm-linux-gnueabihf targets.
Reviewers: labath
Reviewed By: labath
Subscribers: wuzish, nemanjai, kristof.beyls, kbarton, atanasyan, lldb-commits
Differential Revision: https://reviews.llvm.org/D80104
Raphael Isemann