DynamicLoader::LoadBinaryWithUUIDAndAddress() tries a few different ways of finding a binary, and if it can't find an actual binary (and symbol file) on the local computer, it will try to read a binary out of memory, with the thought that there may be a symbol table in memory so we'll get some symbol names. It will create a placeholder name of memory-image-0x.... It seemed like a good idea when I wrote this method, but in practice for binaries outside of userland binaries in a corefile, this hasn't been helpful.
This patch adds a flag to LoadBinaryWithUUIDAndAddress to control if we should create a memory image module, or not. The only case where we still enable this behavior is in ObjectFileMachO::LoadCoreFileImages() when a binary has segment load addresses. This is the case with the "all image infos" LC_NOTE that lldb creates for userland corefiles with binaries that typically have some symbols in their in-memory symbol tables.
The other type of userland corefiles (gcore-created) will not use this LC_NOTE but an entirely different codepath -- through the Darwin userland DynamicLoader plugin -- is taken in those cases, so we'll still read them out of memory.
This patch makes firmware/standalone binary loading not create these memory-image-0x... placeholder binaries with no symbols in them, the scenario where it is more annoying than useful.
The test case TestMultipleBinaryCorefile.py tests this standalone-binary corefile scenario, so it needed adjusting to the new setup where the binary image is not added to the target. I also cleaned up the fake dsym-for-uuid.sh it creates to return a properly formatted DBGError message for https://reviews.llvm.org/D157160
Nit: seems like either allow_memory_image_last_resort or use_memory_image_last_resort would convey the same thing.