On Darwin systems, lldb will call into the DebugSymbols framework to find the debug info (and/or binary) for a given UUID. The user may have set a DBGShellCommands preference in com.apple.DebugSymbols to find that binary by UUID. lldb will also try a binary that is set in the env var LLDB_APPLE_DSYMFORUUID_EXECUTABLE (mostly used by the testsuite) and for certain "force a binary load" binaries (e.g. the Darwin kernel binary/symbols, without which kernel debugging is largely useless), we have a special case in source/Symbol/LocateSymbolFileMacOSX.cpp that knows about a binary called /usr/local/bin/dsymForUUID that may be installed.
These DBGShellCommands programs return a plist (xml) output giving lldb the location of the dSYM and/or binary. They can also return an error message in that xml response. Today lldb does not print that error, making it difficult for users to understand why a binary was not successfully loaded.
I also added some simple logging as lldb processes LC_NOTEs in a mach-o corefile binary that can be enabled, to understand what lldb is seeing as it loads one of these.
I have another patch that I'll be uploading soon where I fix the DBGError return from a test case TestMultipleBinaryCorefile.py, although the error message is sent to the Debugger's Stdout channel so I'm not capturing/testing it in the API test right now. (the dsym-for-uuid.sh that this test case creates DOES emit a DBGError right now on an unknown uuid, but it doesn't format it correctly and lldb ignores it).
If you don't need the Stream anymore you could do