Check for null oso SymbolFile in SymbolFileDwarfDebugMap::ResolveSymbolContext (#89324)

The couple other places that use the oso module's SymbolFile, they check
that it's non-null, so this is just an oversight in
ResolveSymbolContext.

I didn't add a test for this (but did add a log message for the error
case) because I can't see how this would actually happen. The .o file
had to have valid enough DWARF that the linker's parser could handle it
or it would not be in the debug map. If you delete the .o file, we just
leave that entry out of the debug map. If you strip it or otherwise mess
with it, we'll notice the changed mod time and refuse to read it...

This was based on a report from the field, and we don't have access to
the project. But if the logging tells me how this happened I can come
back and add a test with that example.

Author: jimingham

lldb/source/Plugins/SymbolFile/DWARF/SymbolFileDWARFDebugMap.cpp

@@ -848,9 +848,17 @@ SymbolFileDWARFDebugMap::ResolveSymbolContext(const Address &exe_so_addr,
                 debug_map_entry->data.GetOSOFileAddress();
             Address oso_so_addr;
             if (oso_module->ResolveFileAddress(oso_file_addr, oso_so_addr)) {
-              resolved_flags |=
-                  oso_module->GetSymbolFile()->ResolveSymbolContext(
-                      oso_so_addr, resolve_scope, sc);
+              if (SymbolFile *sym_file = oso_module->GetSymbolFile()) {
+                resolved_flags |= sym_file->ResolveSymbolContext(
+                    oso_so_addr, resolve_scope, sc);
+              } else {
+                ObjectFile *obj_file = GetObjectFile();
+                LLDB_LOG(GetLog(DWARFLog::DebugMap),
+                         "Failed to get symfile for OSO: {0} in module: {1}",
+                         oso_module->GetFileSpec(),
+                         obj_file ? obj_file->GetFileSpec()
+                                  : FileSpec("unknown"));
+              }
             }
           }
         }