Don't use Optional::getValue (NFC)

[lldb] Move GetSharedModuleWithLocalCache to PlatformDarwinDevice (NFC)

Refactoring in preparation of D124801.

Differential revision: https://reviews.llvm.org/D124800

[lldb] Fix platform selection on Apple Silicon (again)

This patch is another attempt to fix platform selection on Apple
Silicon. It partially undoes D117340 which tried to fix the issue by
always in

[lldb] Fix platform selection on Apple Silicon (again)

This patch is another attempt to fix platform selection on Apple
Silicon. It partially undoes D117340 which tried to fix the issue by
always instantiating a remote-ios platform for "iPhone and iPad Apps on
Apple Silicon Macs".

While the previous patch worked for attaching, it broke launching and
everything else that expects the remote platform to be connected. I made
an attempt to work around that, but quickly found out that there were
just too may places that had this assumption baked in.

This patch takes a different approach and reverts back to marking the
host platform compatible with iOS triples. This brings us back to the
original situation where platform selection was broken for remote iOS
debugging on Apple Silicon. To fix that, we now look at the process'
host architecture to differentiate between iOS binaries running remotely
and iOS binaries running locally.

I tested the following scenarios, which now all uses the desired
platform:

- Launching an iOS binary on macOS: uses the host platform
- Attaching to an iOS binary on macOS: uses the host platform
- Attaching to a remote iOS binary: uses the remote-ios platform

rdar://89840215

Differential revision: https://reviews.llvm.org/D121444

show more ...

[lldb] Plumb process host architecture through platform selection

To allow us to select a different platform based on where the process is
running, plumb the process host architecture through platfo

[lldb] Plumb process host architecture through platform selection

To allow us to select a different platform based on where the process is
running, plumb the process host architecture through platform selection.

This patch is in preparation for D121444 which needs this functionality
to tell apart iOS binaries running on Apple Silicon vs on a remote iOS
device.

Differential revision: https://reviews.llvm.org/D121484

show more ...

PlatformMacOSX should be activated for lldb built to run on an iOS etc device

In the changes Jonas made in https://reviews.llvm.org/D117340 , a
small oversight was that PlatformMacOSX (despite the n

PlatformMacOSX should be activated for lldb built to run on an iOS etc device

In the changes Jonas made in https://reviews.llvm.org/D117340 , a
small oversight was that PlatformMacOSX (despite the name) is active
for any native Darwin operating system, where lldb and the target
process are running on the same system. This patch uses compile-time
checks to return the appropriate OSType for the OS lldb is being
compiled to, so the "host" platform will correctly be selected when
lldb & the inferior are both running on that OS. And a small change
to PlatformMacOSX::GetSupportedArchitectures which adds additional
recognized triples when running on macOS but not other native Darwin
systems.

Differential Revision: https://reviews.llvm.org/D120517
rdar://89247060

show more ...

[lldb] Use PlatformMacOSX for Mac Catalyst

Use PlatformMacOSX for Mac Catalyst apps on both Intel (x86) and Apple
Silicon (arm64).

[lldb] Fix platform selection on Apple Silicon

Currently, when connecting to a remote iOS device from the command line
on Apple Silicon, we end up using the host platform (PlatfromMacOSX)
instead of

[lldb] Fix platform selection on Apple Silicon

Currently, when connecting to a remote iOS device from the command line
on Apple Silicon, we end up using the host platform (PlatfromMacOSX)
instead of remote-ios (PlatformRemoteiOS). This happens because
PlatfromMacOSX includes arm64-apple-ios and arm64e-apple-ios as
compatible architectures, presumably to support debugging iOS Apps on
Apple Silicon [1].

This is a problem for debugging remote ios devices, because the host
platform doesn't look for an expanded shared cache on disk and as a
result we end up reading everything from memory, incurring a significant
performance hit.

The crux of this patch is to make PlatfromMacOSX *not* compatible with
arm64(e)-apple-ios. This also means that we now use remote-ios
(PlatformRemoteiOS) as the platform for debugging iOS apps on Apple
Silicon. This has the (unintended) side effect that unlike we do for the
host platform, we no longer check our local shared cache, and incur a
performance hit on debugging these apps.

To avoid that, PlatformRemoteiOS now also check the local cache to
support this use case, which is cheap enough to do unconditionally for
PlatformRemoteiOS.

[1] https://support.apple.com/guide/app-store/iphone-ipad-apps-mac-apple-silicon-fird2c7092da/mac

Differential revision: https://reviews.llvm.org/D117340

show more ...

[lldb] Use GetSupportedArchitectures on darwin platforms

This finishes the GetSupportedArchitectureAtIndex migration. There are
opportunities to simplify this even further, but I am going to leave
t

[lldb] Use GetSupportedArchitectures on darwin platforms

This finishes the GetSupportedArchitectureAtIndex migration. There are
opportunities to simplify this even further, but I am going to leave
that to the platform owners.

Differential Revision: https://reviews.llvm.org/D116028

show more ...

[lldb] Remove ConstString from Platform plugin names

[lldb] Treat remote macOS debugging like any other remote darwin platform

Extract remote debugging logic from PlatformMacOSX and move it into
PlatformRemoteMacOSX so it can benefit from all the logi

[lldb] Treat remote macOS debugging like any other remote darwin platform

Extract remote debugging logic from PlatformMacOSX and move it into
PlatformRemoteMacOSX so it can benefit from all the logic necessary for
remote debugging.

Until now, remote macOS debugging was treated almost identical to local
macOS debugging. By moving in into its own class, we can have it inherit
from PlatformRemoteDarwinDevice and all the functionality it provides,
such as looking at the correct DeviceSupport directory.

rdar://68167374

Differential revision: https://reviews.llvm.org/D92452

show more ...

[lldb] GetSharedModule: Collect old modules in SmallVector

The various GetSharedModule methods have an optional out parameter for
the old module when a file has changed or been replaced, which the
T

[lldb] GetSharedModule: Collect old modules in SmallVector

The various GetSharedModule methods have an optional out parameter for
the old module when a file has changed or been replaced, which the
Target uses to keep its module list current/correct. We've been using
a single ModuleSP to track "the" old module, and this change switches
to using a SmallVector of ModuleSP, which has a couple benefits:
- There are multiple codepaths which may discover an old module, and
this centralizes the code for how to handle multiples in one place,
in the Target code. With the single ModuleSP, each place that may
discover an old module is responsible for how it handles multiples,
and the current code is inconsistent (some code paths drop the first
old module, others drop the second).
- The API will be more natural for identifying old modules in routines
that work on sets, like ModuleList::ReplaceEquivalent (which I plan
on updating to report old module(s) in a subsequent change to fix a
bug).

I'm not convinced we can ever actually run into the case that multiple
old modules are found in the same GetOrCreateModule call, but I think
this change makes sense regardless, in light of the above.

When an old module is reported, Target::GetOrCreateModule calls
m_images.ReplaceModule, which doesn't allow multiple "old" modules; the
new code calls ReplaceModule for the first "old" module, and for any
subsequent old modules it logs the event and calls m_images.Remove.

Reviewed By: jingham

Differential Revision: https://reviews.llvm.org/D89156

show more ...

[lldb] Delete copy operations on PluginInterface class

This is a polymorphic class, copying it is a bad idea.

This was not a problem because most classes inheriting from it were
deleting their copy

[lldb] Delete copy operations on PluginInterface class

This is a polymorphic class, copying it is a bad idea.

This was not a problem because most classes inheriting from it were
deleting their copy operations themselves. However, this enables us to
delete those explicit deletions, and ensure noone forgets to add them in
the future.

show more ...

Factor out common code from the iPhone/AppleTV/WatchOS simulator platform plugins. (NFC)

The implementation of these classes was copied & pasted from the
iPhone simulator plugin with only a handful

Factor out common code from the iPhone/AppleTV/WatchOS simulator platform plugins. (NFC)

The implementation of these classes was copied & pasted from the
iPhone simulator plugin with only a handful of configuration
parameters substituted. This patch moves the redundant implementations
into the base class PlatformAppleSimulator.

Differential Revision: https://reviews.llvm.org/D85243

show more ...

[PlatformDarwin] Add support for Apple Silicon.

Gets another large chunk of the testsuite to pass.

Move GetXcode*Directory into HostInfo (NFC)

These functions really don't belong into PlatformDarwin, since they
actualy query state of the Host and not of the remote platform.

Move the Xcode SDK path caching to HostInfo

When debugging a remote platform, the platform you get from
GetPlatformForArchitecture doesn't inherit from PlatformDarwin.
HostInfoMacOSX seems like the

Move the Xcode SDK path caching to HostInfo

When debugging a remote platform, the platform you get from
GetPlatformForArchitecture doesn't inherit from PlatformDarwin.
HostInfoMacOSX seems like the right place to have a global store of
local paths.

Differential Revision: https://reviews.llvm.org/D79364

show more ...

Remap the target (Xcode) SDK directory to the host SDK directory.

This is mostly useful for Swift support; it allows LLDB to substitute
a matching SDK it shipped with instead of the sysroot path tha

Remap the target (Xcode) SDK directory to the host SDK directory.

This is mostly useful for Swift support; it allows LLDB to substitute
a matching SDK it shipped with instead of the sysroot path that was
used at compile time.

The goal of this is to make the Xcode SDK something that behaves more
like the compiler's resource directory, as in that it ships with LLDB
rather than with the debugged program. This important primarily for
importing Swift and Clang modules in the expression evaluator, and
getting at the APINotes from the SDK in Swift.

For a cross-debugging scenario, this means you have to have an SDK for
your target installed alongside LLDB. In Xcode this will always be the
case.

rdar://problem/60640017

Differential Revision: https://reviews.llvm.org/D76471

show more ...

[lldb/PlatformDarwin] Be more robust in computing the SDK path with xcrun

The current implementation isn't very resilient when it comes to the
output of xcrun. Currently it cannot deal with:

- Tra

[lldb/PlatformDarwin] Be more robust in computing the SDK path with xcrun

The current implementation isn't very resilient when it comes to the
output of xcrun. Currently it cannot deal with:

- Trailing newlines.
- Leading newlines and errors/warnings before the Xcode path.
- Xcode not being named Xcode.app.

This extract the logic into a helper in PlatformDarwin and fixes those
issues. It's also the first step towards removing code duplication
between the different platforms and downstream Swift.

Differential revision: https://reviews.llvm.org/D76261

show more ...

[lldb/Plugin] s/LLDB_PLUGIN/LLDB_PLUGIN_DEFINE/ (NFC)

Rename LLDB_PLUGIN to LLDB_PLUGIN_DEFINE as Pavel suggested in D73067 to
avoid name conflict.

[lldb/Plugins] Move PlatformRemoteiOS into PlatformMacOSX (NFCI)

Move the logic for initialization and termination for PlatformRemoteiOS
into PlatformMacOSX, like we did for the other Darwin platfor

[lldb/Plugins] Move PlatformRemoteiOS into PlatformMacOSX (NFCI)

Move the logic for initialization and termination for PlatformRemoteiOS
into PlatformMacOSX, like we did for the other Darwin platforms in
a731c6ba94d0464c6a122de1af70ab88ffb5c1a6.

show more ...

[LLDB] Fix GCC warnings about extra semicolons. NFC.

[lldb/Plugins] Use external functions to (de)initialize plugins

This is a step towards making the initialize and terminate calls be
generated by CMake, which in turn is towards making it possible to

[lldb/Plugins] Use external functions to (de)initialize plugins

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

show more ...

[lldb][NFC] Fix all formatting errors in .cpp file headers

Summary:
A *.cpp file header in LLDB (and in LLDB) should like this:
```
//===-- TestUtilities.cpp ----------------------------------------

[lldb][NFC] Fix all formatting errors in .cpp file headers

Summary:
A *.cpp file header in LLDB (and in LLDB) should like this:
```
//===-- TestUtilities.cpp -------------------------------------------------===//
```
However in LLDB most of our source files have arbitrary changes to this format and
these changes are spreading through LLDB as folks usually just use the existing
source files as templates for their new files (most notably the unnecessary
editor language indicator `-*- C++ -*-` is spreading and in every review
someone is pointing out that this is wrong, resulting in people pointing out that this
is done in the same way in other files).

This patch removes most of these inconsistencies including the editor language indicators,
all the different missing/additional '-' characters, files that center the file name, missing
trailing `===//` (mostly caused by clang-format breaking the line).

Reviewers: aprantl, espindola, jfb, shafik, JDevlieghere

Reviewed By: JDevlieghere

Subscribers: dexonsmith, wuzish, emaste, sdardis, nemanjai, kbarton, MaskRay, atanasyan, arphaman, jfb, abidh, jsji, JDevlieghere, usaxena95, lldb-commits

Tags: #lldb

Differential Revision: https://reviews.llvm.org/D73258

show more ...

[lldb/Platform] Re-add ifdef's to guard macOS-only code.

I moved the code from the system initializer to PlatformMacOSX. The
defines are still necessary because MacOSX is initialized on other
platfo

[lldb/Platform] Re-add ifdef's to guard macOS-only code.

I moved the code from the system initializer to PlatformMacOSX. The
defines are still necessary because MacOSX is initialized on other
platforms where the other platforms are not available.

show more ...

[lldb/Initializers] Move all macOS initializers into PlatformMacOSX

PlatformMacOSX is the main entry point to the plugin with the same name.
This is part of a greater refactoring to auto generate th

[lldb/Initializers] Move all macOS initializers into PlatformMacOSX

PlatformMacOSX is the main entry point to the plugin with the same name.
This is part of a greater refactoring to auto generate the initializers.

Differential revision: https://reviews.llvm.org/D73116

show more ...