Ignore DBGArchitecture from DebugSymbols DBGShellCommands outputs

[jasonmolenda]

Summary

The plist returned by a DBGShellCommands program (dsymForUUID etc) may include an architecture in the DBGArchitecture kv. lldb uses this to fill in the ArchSpec of the ModuleSpec it returns along with the executable/dsym file path. The bug I'm fixing here is that lldb and the provider of DBGArchitecture may *disagree* about what the architecture is called, and when lldb tries to load the actual binary, it will find that the ArchSpec of the binary does not match the ModuleSpec it is looking for, and ignore the binary.

In the specific case I'm fixing, it was an arm cortex-m corefile where lldb calls it armv7em, but dwarfdump (I suspect) was calling it thumbv7em to for MC to treat the instructions as pure thumb (lldb does the same when it creates the MCDisassembler). The process of picking the matching ModuleSpec is looking for an exact match, and this fails.

The architecture in the plist is of little importance, we're working with binaries with UUIDs and that is what we need to be depending on. I thought about different ways of trying to address this, and ultimately, ignoring DBGArchitecture which adds no benefits to lldb, is the best.

rdar://problem/71612561

[jasonmolenda]

Ah, I forgot to add. I added a test by having an existing corefile test (which loads an x86_64 binary) have a plist that claims it is i386. It's close to the same thing, and results in the same kind of erroring if lldb trusts the arch from the plist.

[JDevlieghere]

LGTM

lldb/source/Symbol/LocateSymbolFileMacOSX.cpp

if (cf_str && CFGetTypeID(cf_str) == CFStringGetTypeID()) {
         success = true;
         if (log) {
           LLDB_LOGF(log, "From dsymForUUID plist: dSYM is at '%s'",
                     str.c_str());
         }
       }
     }
 
-    cf_str = (CFStringRef)CFDictionaryGetValue((CFDictionaryRef)uuid_dict,
-                                               CFSTR("DBGArchitecture"));
-    if (cf_str && CFGetTypeID(cf_str) == CFStringGetTypeID()) {
-      if (CFCString::FileSystemRepresentation(cf_str, str))
-        module_spec.GetArchitecture().SetTriple(str.c_str());
-    }
-
     std::string DBGBuildSourcePath;
     std::string DBGSourcePath;
 
     // If DBGVersion 1 or DBGVersion missing, ignore DBGSourcePathRemapping.
     // If DBGVersion 2, strip last two components of path remappings from
     //                  entries to fix an issue with a specific set of
     //                  DBGSourcePathRemapping entries that lldb worked
     //                  with.

lldb/test/API/macosx/lc-note/firmware-corefile/TestFirmwareCorefiles.py

def test_lc_note(self):
                 '  dsym=%s.dSYM/Contents/Resources/DWARF/%s' % (self.aout_exe, os.path.basename(self.aout_exe)),
                 'else',
                 '  uuid=%s' % bout_uuid,
                 '  bin=%s' % self.bout_exe,
                 '  dsym=%s.dSYM/Contents/Resources/DWARF/%s' % (self.bout_exe, os.path.basename(self.bout_exe)),
                 'fi',
                 'echo "<dict><key>$uuid</key><dict>"',
                 '',
-                'echo "<key>DBGArchitecture</key><string>x86_64</string>"',
+                'echo "<key>DBGArchitecture</key><string>i386</string>"',
                 'echo "<key>DBGDSYMPath</key><string>$dsym</string>"',
                 'echo "<key>DBGSymbolRichExecutable</key><string>$bin</string>"',
                 'echo "</dict></dict></plist>"',
                 'exit $ret'
                 ]
 
         with open(self.dsym_for_uuid, "w") as writer:
             for l in shell_cmds: