[Target] Move ObjCLanguageRuntime::LookupRuntimeSymbol into LanguageRuntime

[xiaobai]

Summary

LookupRuntimeSymbol seems like a general LanguageRuntime method.
Although no other language runtime currently implements this, there's no
reason another language runtime couldn't use this.

Additionally, this breaks IRExecutionUnit's dependency on
ObjCLanguageRuntime.

[labath]

If this is supposed to be truly language-agnostic, shouldn't we be iterating over all language plugins and asking all of them for the "runtime symbol" (not that I know what a runtime symbol is, really)?

Otherwise, this is still language-specific behavior, even though it's not visible to the linker because it's hidden by an enum and a virtual interface.

[xiaobai]

In D62795#1527035, @labath wrote:

If this is supposed to be truly language-agnostic, shouldn't we be iterating over all language plugins and asking all of them for the "runtime symbol" (not that I know what a runtime symbol is, really)?

Otherwise, this is still language-specific behavior, even though it's not visible to the linker because it's hidden by an enum and a virtual interface.

Mmm, yes, you're right, that should be happening. The function is FindInRuntimes, not FindInObjCRuntime after all. Thanks for pointing that out, let me change that.

[xiaobai]

Make the behavior in IRExecutionUnit actually language agnostic.

Also, reverse the order of the for loops.

[clayborg]

include/lldb/Target/ObjCLanguageRuntime.h

270–272

Which language has this filled in? Only Swift?

[xiaobai]

include/lldb/Target/ObjCLanguageRuntime.h

270–272

Objective-C is the only thing that has this filled in at the moment, as I understand it.

[clayborg]

include/lldb/Target/ObjCLanguageRuntime.h

270–272

There must be a V1 or V2 implementation somewhere? From the looks of things here, it seems like we are pulling it out, but that must not be what is happening. So the V1 and V2 impls must have this already set as "lldb::addr_t LookupRuntimeSymbol(ConstString name) override;"?

[xiaobai]

include/lldb/Target/ObjCLanguageRuntime.h

270–272

Yes, AppleObjCRuntimeV2 has an override for this method.

[jingham]

This looks fine to me.

For context, ObjC has symbols that point into the runtime that tell you things like the current offsets of the members of an ObjC class. In debug builds the symbols are present, but the runtime doesn't depend on the symbols per se, since it reads the data directly from the runtime. The symbol names are constructed from the class & ivar name so they are a convenient way to name the data you are looking for. The lldb does "look for the symbol and if you don't find it ask the runtime if it knows where the equivalent data lives directly in the runtime.". The latter task is "LookupRuntimeSymbol".

We don't do it this way in swift, instead we ask RemoteAST for this sort of data.

include/lldb/Target/LanguageRuntime.h

public:
 
   // Called by ClangExpressionParser::PrepareForExecution to query for any
   // custom LLVM IR passes that need to be run before an expression is
   // assembled and run.
   virtual bool GetIRPasses(LLVMUserExpression::IRPasses &custom_passes) {
     return false;
   }
 
+  // Given the name of a runtime symbol (e.g. in Objective-C, an ivar offset
+  // symbol), try to determine from the runtime what the value of that symbol
+  // would be. Useful when the underlying binary is stripped.
+  virtual lldb::addr_t LookupRuntimeSymbol(ConstString name) {
+    return LLDB_INVALID_ADDRESS;
+  }
+
 protected:
   // Classes that inherit from LanguageRuntime can see and modify these
 
   LanguageRuntime(Process *process);
   Process *m_process;
 
 private:
   DISALLOW_COPY_AND_ASSIGN(LanguageRuntime);
 };
 
 } // namespace lldb_private
 
 #endif // liblldb_LanguageRuntime_h_

include/lldb/Target/ObjCLanguageRuntime.h

public:
   virtual DeclVendor *GetDeclVendor() { return nullptr; }
 
   // Finds the byte offset of the child_type ivar in parent_type.  If it can't
   // find the offset, returns LLDB_INVALID_IVAR_OFFSET.
 
   virtual size_t GetByteOffsetForIvar(CompilerType &parent_qual_type,
                                       const char *ivar_name);
 
-  // Given the name of an Objective-C runtime symbol (e.g., ivar offset
-  // symbol), try to determine from the runtime what the value of that symbol
-  // would be. Useful when the underlying binary is stripped.
-  virtual lldb::addr_t LookupRuntimeSymbol(ConstString name) {
-    return LLDB_INVALID_ADDRESS;
-  }
-
   bool HasNewLiteralsAndIndexing() {
     if (m_has_new_literals_and_indexing == eLazyBoolCalculate) {
       if (CalculateHasNewLiteralsAndIndexing())
         m_has_new_literals_and_indexing = eLazyBoolYes;
       else
         m_has_new_literals_and_indexing = eLazyBoolNo;
     }
 

source/Expression/IRExecutionUnit.cpp

 #include "lldb/Core/Module.h"
 #include "lldb/Core/Section.h"
 #include "lldb/Expression/IRExecutionUnit.h"
 #include "lldb/Symbol/CompileUnit.h"
 #include "lldb/Symbol/SymbolContext.h"
 #include "lldb/Symbol/SymbolFile.h"
 #include "lldb/Symbol/SymbolVendor.h"
 #include "lldb/Target/ExecutionContext.h"
-#include "lldb/Target/ObjCLanguageRuntime.h"
+#include "lldb/Target/LanguageRuntime.h"
 #include "lldb/Target/Target.h"
 #include "lldb/Utility/DataBufferHeap.h"
 #include "lldb/Utility/DataExtractor.h"
 #include "lldb/Utility/LLDBAssert.h"
 #include "lldb/Utility/Log.h"
 
 #include "lldb/../../source/Plugins/Language/CPlusPlus/CPlusPlusLanguage.h"
 #include "lldb/../../source/Plugins/ObjectFile/JIT/ObjectFileJIT.h"
IRExecutionUnit::FindInRuntimes(const std::vector<SearchSpec> &specs,
   }
 
   lldb::ProcessSP process_sp = sc.target_sp->GetProcessSP();
 
   if (!process_sp) {
     return LLDB_INVALID_ADDRESS;
   }
 
-  ObjCLanguageRuntime *runtime = process_sp->GetObjCLanguageRuntime();
-
-  if (runtime) {
-    for (const SearchSpec &spec : specs) {
+    for (LanguageRuntime *runtime : process_sp->GetLanguageRuntimes()) {
       lldb::addr_t symbol_load_addr = runtime->LookupRuntimeSymbol(spec.name);
 
       if (symbol_load_addr != LLDB_INVALID_ADDRESS)
         return symbol_load_addr;
     }
   }
 
   return LLDB_INVALID_ADDRESS;