[all-commits] [llvm/llvm-project] e31b2d: [lldb][crashlog] Avoid specifying arch for image w...

[Vedant Kumar via All-commits]

  Branch: refs/heads/main
  Home:   https://github.com/llvm/llvm-project
  Commit: e31b2d7d7be98cbbaa665b2702cd0ed2975da4cc
      https://github.com/llvm/llvm-project/commit/e31b2d7d7be98cbbaa665b2702cd0ed2975da4cc
  Author: Vedant Kumar <vsk at apple.com>
  Date:   2021-09-20 (Mon, 20 Sep 2021)

  Changed paths:
    M lldb/examples/python/symbolication.py

  Log Message:
  -----------
  [lldb][crashlog] Avoid specifying arch for image when a UUID is present

When adding an image to a target for crashlog purposes, avoid specifying
the architecture of the image.

This has the effect of making SBTarget::AddModule infer the ArchSpec for
the image based on the SBTarget's architecture, which LLDB puts serious
effort into calculating correctly (in TargetList::CreateTargetInternal).

The status quo is that LLDB randomly guesses the ArchSpec for a module
if its architecture is specified, via:

```
  SBTarget::AddModule -> Platform::GetAugmentedArchSpec -> Platform::IsCompatibleArchitecture ->
GetSupportedArchitectureAtIndex -> {ARM,x86}GetSupportedArchitectureAtIndex
```

... which means that the same crashlog can fail to load on an Apple
Silicon Mac (due to the random guess of arm64e-apple-macosx for the
module's ArchSpec not being compatible with the SBTarget's (correct)
ArchSpec), while loading just fine on an Intel Mac.

I'm not sure how to add a test for this (it doesn't look like there's
test coverage of this path in-tree). It seems like it would be pretty
complicated to regression test: the host LLDB would need to be built for
arm64e, we'd need a hand-crafted arm64e iOS crashlog, and we'd need a
binary with an iOS deployment target. I'm open to other / simpler
options.

rdar://82679400

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