Add a new state for UnwindPlan::Row which indicates that any
register not listed is not defined, and should not be found in
stack frames newer than this one and passed up the stack. Mostly
intended for use with architectural default unwind plans that are
used for jitted stack frames, where we have no unwind information
or start address. lldb has no way to tell if registers were
spilled in the jitted frame & overwritten, so passing register
values up the stack is not safe to show the user.
Architectural default unwind plans are also used as a fast unwind
plan on x86_64 in particular, and are used as the fallback unwind
plans when lldb thinks it may be able to work around a problem
which causes the unwinder to stop walking the stack early.
For fast unwind plans, when we don't find a register location in
the arch default unwind plan, we fall back to computing & using
the full unwind plan. One small part of this patch is to know that
a register marked as Undefined in the fast unwind plan is a special
case, and we should continue on to the full unwind plan to find what
the real unwind rule is for this register.
Differential Revision: https://reviews.llvm.org/D96829
<rdar://problem/70398009>
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
LLDB has a few different styles of header guards and they're not very
consistent because things get moved around or copy/pasted. This patch
unifies the header guards across LLDB and converts everything to match
LLVM's style.
Differential revision: https://reviews.llvm.org/D74743
After the recent change that grouped some of the ABI plugins together,
those plugins ended up with multiple initializers per plugin. This is
incompatible with my proposed approach of generating the initializers
dynamically, which is why I've grouped them together in a new entry
point.
Differential revision: https://reviews.llvm.org/D74451
Summary:
This patch creates a new subclass of the ABI class in order to abstract away the
mechanism in which we "augment" register information. This enables alternate
augmentation strategies to be introduced.
All existing ABI classes have been modified to inherit from RegInfoBasedABI, but
they will be refactored in subsequent patches.
Reviewers: JDevlieghere, jasonmolenda
Subscribers: sdardis, nemanjai, kbarton, jrtc27, atanasyan, jsji, lldb-commits
Tags: #lldb
Differential Revision: https://reviews.llvm.org/D74243
This is a step towards making the initialize and terminate calls be
generated by CMake, which in turn is towards making it possible to
disable plugins at configuration time.
Differential revision: https://reviews.llvm.org/D74245
Summary:
There's a fair amount of code duplication between the different ABI plugins for
the same architecture (e.g. ABIMacOSX_arm & ABISysV_arm). Deduplicating this
code is not very easy at the moment because there is no good place where to put
the common code.
Instead of creating more plugins, this patch reduces their number by grouping
similar plugins into a single folder/plugin. This makes it easy to extract
common code to a (e.g.) base class, which can then live in the same folder.
The grouping is done based on the underlying llvm target for that architecture,
because the plugins already require this for their operation.
Reviewers: JDevlieghere, jasonmolenda, jfb
Subscribers: sdardis, nemanjai, mgorny, kristof.beyls, fedor.sergeev, kbarton, jrtc27, atanasyan, jsji, lldb-commits
Tags: #lldb
Differential Revision: https://reviews.llvm.org/D74138
Jason Molenda