As is common with curses apps, this allows to redraw everything
in case something corrupts the screen. Apparently key modifiers
are difficult with curses (curses FAQ it "doesn't do that"),
thankfully Ctrl+key are simply control characters, so it's
(ascii & 037) => 12.
Differential Revision: https://reviews.llvm.org/D84972
On an iOS device, if debugserver is left to figure out how to launch
the binary provided, it looks at the filename to see if it contains
".app" and asks FrontBoard to launch it. However, if this is actually
a command line app with the characters ".app" in the name, it would
end up trying to launch that via the FrontBoard calls even though it
needed to be launched via posix_spawn. For instance, a command line
program called com.application.tester.
Jim suggested this patch where we only send binaries that end in ".app"
to FrontBoard.
Often debugsever is invoked with a --launch command line argument to
specify the launch method, and none of this code is hit in that
instance.
<rdar://problem/65297100>
This test was added in D74217 (and the `.categories` file later added in ccf1c30cde) around the same time I moved the test tree from `lldb/packages/Python/lldbsuite/test` to `lldb/test/API` (D71151). Since this got lost in the move, it isn't running. (I introduced an intentional syntax error, and `ninja check-lldb` passes).
I moved it to the correct location, and now it runs and passes -- locally, at least -- as `ninja check-lldb-api-tools-lldb-server-registers-target-xml-reading`.
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
Move the finish_swig logic into a function in the bindings directory. By
making this a function I can reuse the logic internally where we ship
two Python versions and therefore need to finish the bindings twice.
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
'd' would be much better used for up/down shortcuts, and this also removes
the possibility of ruining the whole debugging session by accidentally
hitting 'd' or 'k'. Also change menu to have both 'detach and resume'
and 'detach suspended' to make it clear which one is which. See
discussion at https://reviews.llvm.org/D68541 .
Differential Revision: https://reviews.llvm.org/D68908
Both of BreakpointLocation and BreakpointSite were inherited from StoppointLocation. However, the only thing
they shared was hit counting logic. The patch encapsulates those logic into StoppointHitCounter, renames
StoppointLocation to StoppointSite, and stops BreakpointLocation's inheriting from it.
Differential Revision: https://reviews.llvm.org/D84527
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
Currently, `target create` has no --platform option. However,
TargetList::CreateTargetInternal which is called under the hood, will
return an error when either no platform or multiple matching platforms
are found, saying that a platform should be specified with --platform.
This patch adds the platform option, but that doesn't solve either of
these errors.
- If more than one platform matches, specifying the platform isn't
going to fix that. The current code will only look at the
architecture instead. I've updated the error message to ask the user
to specify an architecture.
- If no architecture is found, specifying a new one via platform isn't
going to change that either because we already try to find one that
matches the given architecture.
Differential revision: https://reviews.llvm.org/D84809
Summary:
Initially, Apple simulator binarie triples didn't use a `-simulator`
environment and were just differentiated based on the architecture.
For example, `x86_64-apple-ios` would obviously be a simualtor as iOS
doesn't run on x86_64. With Catalyst, we made the disctinction
explicit and today, all simulator triples (even the legacy ones) are
constructed with an environment. This is especially important on Apple
Silicon were the architecture is not different from the one of the
simulated device.
This change makes the simulator part of the environment always part of
the criteria to detect whether 2 `ArchSpec`s are equal or compatible.
Reviewers: aprantl
Subscribers: inglorion, dexonsmith, lldb-commits
Tags: #lldb
Differential Revision: https://reviews.llvm.org/D84716
This way, downstream projects don't have to invoke find_package(ZLIB)
reducing the amount of boilerplate.
Differential Revision: https://reviews.llvm.org/D84691
This cleanup patch unifies all methods called GetByteSize() in the
ValueObject hierarchy to return an optional, like the methods in
CompilerType do. This means fewer magic 0 values, which could fix bugs
down the road in languages where types can have a size of zero, such
as Swift and C (but not C++).
Differential Revision: https://reviews.llvm.org/D84285
This re-lands the patch with bogus :m_byte_size(0) initalizations removed.
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 way we can get rid of this 1024 char buffer workaround.
Reviewers: #lldb, labath
Reviewed By: labath
Subscribers: JDevlieghere
Differential Revision: https://reviews.llvm.org/D84528
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
The function didn't combine a large entry which overlapped several other
entries, if those other entries were not overlapping among each other.
E.g., (0,20),(5,6),(10,11) produced (0,20),(10,11)
Now it just produced (0,20).
This cleanup patch unifies all methods called GetByteSize() in the
ValueObject hierarchy to return an optional, like the methods in
CompilerType do. This means fewer magic 0 values, which could fix bugs
down the road in languages where types can have a size of zero, such
as Swift and C (but not C++).
Differential Revision: https://reviews.llvm.org/D84285
If a module has debug info, the size of debug symbol will be displayed after the Symbols Loaded Message for each module in the VScode modules view.{F12335461}
Reviewed By: wallace, clayborg
Differential Revision: https://reviews.llvm.org/D83731
Adrian Prantl