[Lldb-commits] [lldb] [LLDB] Serve unknown type symbols through `qSymbol` (PR #200134)

[David Spickett via lldb-commits]

================
@@ -4156,41 +4158,55 @@ void GDBRemoteCommunicationClient::ServeSymbolLookups(
                 if (symbol_load_addr != LLDB_INVALID_ADDRESS)
                   break;
                 if (sc.symbol) {
-                  switch (sc.symbol->GetType()) {
-                  case eSymbolTypeInvalid:
-                  case eSymbolTypeAbsolute:
-                  case eSymbolTypeUndefined:
-                  case eSymbolTypeSourceFile:
-                  case eSymbolTypeHeaderFile:
-                  case eSymbolTypeObjectFile:
-                  case eSymbolTypeCommonBlock:
-                  case eSymbolTypeBlock:
-                  case eSymbolTypeLocal:
-                  case eSymbolTypeParam:
-                  case eSymbolTypeVariable:
-                  case eSymbolTypeVariableType:
-                  case eSymbolTypeLineEntry:
-                  case eSymbolTypeLineHeader:
-                  case eSymbolTypeScopeBegin:
-                  case eSymbolTypeScopeEnd:
-                  case eSymbolTypeAdditional:
-                  case eSymbolTypeCompiler:
-                  case eSymbolTypeInstrumentation:
-                  case eSymbolTypeTrampoline:
-                    break;
-
-                  case eSymbolTypeCode:
-                  case eSymbolTypeResolver:
-                  case eSymbolTypeData:
-                  case eSymbolTypeRuntime:
-                  case eSymbolTypeException:
-                  case eSymbolTypeObjCClass:
-                  case eSymbolTypeObjCMetaClass:
-                  case eSymbolTypeObjCIVar:
-                  case eSymbolTypeReExported:
+                  if (sc.module_sp->GetArchitecture()
+                          .GetTriple()
+                          .getObjectFormat() ==
+                      llvm::Triple::ObjectFormatType::MachO) {
+                    switch (sc.symbol->GetType()) {
+                    case eSymbolTypeInvalid:
+                    case eSymbolTypeAbsolute:
+                    case eSymbolTypeUndefined:
+                    case eSymbolTypeSourceFile:
+                    case eSymbolTypeHeaderFile:
+                    case eSymbolTypeObjectFile:
+                    case eSymbolTypeCommonBlock:
+                    case eSymbolTypeBlock:
+                    case eSymbolTypeLocal:
+                    case eSymbolTypeParam:
+                    case eSymbolTypeVariable:
+                    case eSymbolTypeVariableType:
+                    case eSymbolTypeLineEntry:
+                    case eSymbolTypeLineHeader:
+                    case eSymbolTypeScopeBegin:
+                    case eSymbolTypeScopeEnd:
+                    case eSymbolTypeAdditional:
+                    case eSymbolTypeCompiler:
+                    case eSymbolTypeInstrumentation:
+                    case eSymbolTypeTrampoline:
+                      break;
+
+                    case eSymbolTypeCode:
+                    case eSymbolTypeResolver:
+                    case eSymbolTypeData:
+                    case eSymbolTypeRuntime:
+                    case eSymbolTypeException:
+                    case eSymbolTypeObjCClass:
+                    case eSymbolTypeObjCMetaClass:
+                    case eSymbolTypeObjCIVar:
+                    case eSymbolTypeReExported:
+                      symbol_load_addr =
+                          sc.symbol->GetLoadAddress(&process->GetTarget());
+                      break;
+                    }
+                  } else {
+                    // GDB does return symbols even when they're not valid
+                    // address, following this behavior on non Mach-O
----------------
DavidSpickett wrote:

"valid addresses" plural, but I think it would be better to say "even when they are of an unknown type".

As you have said in one of your comments that these symbols may in fact be addresses with the debugee's address space. Some of them might not be, but they could be, if I understood correctly.

https://github.com/llvm/llvm-project/pull/200134