[lldb][crashlog] Avoid specifying arch for image when a UUID is present

[vsk]

Summary

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

[jasonmolenda]

Yeah, on macOS we'll always have a UUID so this is a good change. The only time an arch is really important is if we don't have a UUID and we have a universal binary (aka fat file) & need to select the correct architecture.

[aprantl]

Without having dug into this deeper, do you think not specifying the arch could cause any problems with universal binaries? I guess not, because we still have the UUID, and the UUID is per arch?

[vsk]

In D110013#3013733, @aprantl wrote:

Without having dug into this deeper, do you think not specifying the arch could cause any problems with universal binaries? I guess not, because we still have the UUID, and the UUID is per arch?

Exactly. The bug in question actually did source universal binaries: CreateTargetInternal was able to select the correct slice based on the UUID.

[jasonmolenda]

In D110013#3013733, @aprantl wrote:

Without having dug into this deeper, do you think not specifying the arch could cause any problems with universal binaries? I guess not, because we still have the UUID, and the UUID is per arch?

Yeah in the no-UUID case we need to depend on a filepath and an arch to uniquely identify a binary (and hope that the filepath is the same binary). In practice we see UUIDs for all binaries on darwin systems in crash reports.

lldb/examples/python/symbolication.py

def add_module(self, target):
             if uuid_str:
                 self.module = target.AddModule(None, None, uuid_str)
             if not self.module:
                 self.locate_module_and_debug_symbols()
                 if self.unavailable:
                     return None
                 resolved_path = self.get_resolved_path()
                 self.module = target.AddModule(
-                    resolved_path, str(self.arch), uuid_str, self.symfile)
+                    resolved_path, None, uuid_str, self.symfile)
             if not self.module:
                 return 'error: unable to get module for (%s) "%s"' % (
                     self.arch, self.get_resolved_path())
             if self.has_section_load_info():
                 return self.load_module(target)
             else:
                 return None  # No sections, the module was added to the target, so success
         else: