Currently, all data buffers are assumed to be writable. This is a
problem on macOS where it's not allowed to load unsigned binaries in
memory as writable. To be more precise, MAP_RESILIENT_CODESIGN and
MAP_RESILIENT_MEDIA need to be set for mapped (unsigned) binaries on our
platform.
Binaries are mapped through FileSystem::CreateDataBuffer which returns a
DataBufferLLVM. The latter is backed by a llvm::WritableMemoryBuffer
because every DataBuffer in LLDB is considered to be writable. In order
to use a read-only llvm::MemoryBuffer I had to split our abstraction
around it.
This patch distinguishes between a DataBuffer (read-only) and
WritableDataBuffer (read-write) and updates LLDB to use the appropriate
one.
rdar://74890607
Differential revision: https://reviews.llvm.org/D122856
Most of our code was including Log.h even though that is not where the
"lldb" log channel is defined (Log.h defines the generic logging
infrastructure). This worked because Log.h included Logging.h, even
though it should.
After the recent refactor, it became impossible the two files include
each other in this direction (the opposite inclusion is needed), so this
patch removes the workaround that was put in place and cleans up all
files to include the right thing. It also renames the file to LLDBLog to
better reflect its purpose.
This reverts commit ef82063207.
- It conflicts with the existing llvm::size in STLExtras, which will now
never be called.
- Calling it without llvm:: breaks C++17 compat
There is no reason why this function should be returning a ConstString.
While modifying these files, I also fixed several instances where
GetPluginName and GetPluginNameStatic were returning different strings.
I am not changing the return type of GetPluginNameStatic in this patch, as that
would necessitate additional changes, and this patch is big enough as it is.
Differential Revision: https://reviews.llvm.org/D111877
The previous version of the patch did not update the definitions in
conditionally compiled code. This patch includes changes to ARC and
windows targets.
Original commit message was:
These were added to support some mips registers on linux, but linux mips
support has now been removed due.
They are still referenced in the freebds mips implementation, but the
completeness of that implementation is also unknown. All other
architectures just set these fields to zero, which is a cause of
significant bloat in our register info definitions.
Arm also has registers with variable sizes, but they were implemented in
a more gdb-compatible fashion and don't use this feature.
Differential Revision: https://reviews.llvm.org/D110914
This reverts commit 00e704bf08.
This commit should should have updated
llvm/llvm-project/lldb/source/Plugins/ABI/ARC/ABISysV_arc.cpp like the other
architectures.
These were added to support some mips registers on linux, but linux mips
support has now been removed due.
They are still referenced in the freebds mips implementation, but the
completeness of that implementation is also unknown. All other
architectures just set these fields to zero, which is a cause of
significant bloat in our register info definitions.
Arm also has registers with variable sizes, but they were implemented in
a more gdb-compatible fashion and don't use this feature.
Differential Revision: https://reviews.llvm.org/D110914
Remove redundant register alt_names that correspond to their respective
generic names. D108554 makes it possible to query registers through
their generic names directly, therefore making repeating them via
alt_name unnecessary.
While at it, also remove alt_names that are equal to register names
on PPC.
This patch does not alter register definitions where the generic names
are listed as primary names, and other names are provided as alt_name
(e.g. ARM).
Differential Revision: https://reviews.llvm.org/D109626
In all these years, we haven't found a use for this function (it has
zero callers). Lets just remove the boilerplate.
Differential Revision: https://reviews.llvm.org/D109600
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>
RegisterInfo's `reg_name`/`reg_alt_name` fields are C-Strings and are supposed
to only be generated from a ConstString. The reason for that is that
`DynamicRegisterInfo::GetRegisterInfo` and
`RegInfoBasedABI::GetRegisterInfoByName` try to optimise finding registers by
name by only comparing the C string pointer values instead of the underlying
strings. This only works if both C strings involved in the comparison come from
a ConstString. If one of the two C strings doesn't come from a ConstString the
comparison won't work (and most likely will silently fail).
I added an assert in b0060c3a78 which checks that
both strings come from a ConstString. Apparently not all ABI plugins are
generating their register names via ConstString, so this code is now not just
silently failing but also asserting.
In D88375 we did a shady fix for the MIPS plugins by just copying the
ConstString setup code to that plugin, but we still need to fix ABISysV_arc,
ABISysV_ppc and ABISysV_ppc64 plugins.
I would say we just fix the remaining plugins by removing the whole requirement
to have the register names coming from ConstStrings. I really doubt that we
actually save any time with the whole ConstString search trick (searching ~50
strings that have <4 characters doesn't sound more expensive than calling the
really expensive ConstString constructor + comparing the same amount of pointer
values). Also whatever small percentage of LLDB's runtime is actually spend in
this function is anyway not worth the complexity of this approach.
This patch just removes all this and just does a normal string comparison.
Reviewed By: JDevlieghere, labath
Differential Revision: https://reviews.llvm.org/D88490
RegInfoBasedABI::GetRegisterInfoByName was failing because mips/mips64 ABIs
don't use ConstString in their register info array.
Reviewed By: #lldb, teemperor
Differential Revision: https://reviews.llvm.org/D88375
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
Jonas Devlieghere