Symbolizer - Teach symbolizer to work directly on object file.

[pvellien]

Summary

This patch intended to provide additional interface to LLVMsymbolizer such that they work directly on object files. There is an existing method - symbolizecode which takes an object file, this patch provides similar overloads for symbolizeInlinedCode, symbolizeData, symbolizeFrame. This can be useful for clients who already have a in-memory object files to symbolize for.

[scott.linder]

llvm/lib/DebugInfo/Symbolize/Symbolize.cpp

73–74

See below, it seems like this is just a bug currently?

579–602

The logic for CoffObject is not repeated elsewhere, which doesn't seem intended?

It seems like this method should also be overloaded, i.e. rather than repeat the "try to find it, if not create it" logic in each overload above, just implement LLVMSymbolizer::getOrCreateModuleInfo(const ObjectFile &) too, and the bodies elsewhere should become identical. I'd also consider just making the private *Common methods templates over the type of the first argument, and have the overloads be one-line wrappers:

template <typename T>
Expected<DILineInfo> symbolizeCommonCode(T ModuleSpecifier, object::SectionedAddress ModuleOffset) {
    SymbolizableModule *Info;
    if (auto InfoOrErr = getOrCreateModuleInfo(ModuleSpecifier))
      Info = InfoOrErr.get();
    else
      return InfoOrErr.takeError();
    // ... the existing body in terms of Info and ModuleOffset
}
Expected<DILineInfo> LLVMSymbolizer::symbolizeCode(const std::string &ModuleName, object::SectionedAddress ModuleOffset) { return symbolizeCodeCommon(ModuleName, ModuleOffset); }
Expected<DILineInfo> LLVMSymbolizer::symbolizeCode(const ObjectFile &ModuleObjectFile, object::SectionedAddress ModuleOffset) { return symbolizeCodeCommon(ModuleObjectFile, ModuleOffset); }

I think this minimizes the amount of boilerplate, short of using the preprocessor, while still presenting the nice overloaded interface rather than the templated one.

[scott.linder]

llvm/lib/DebugInfo/Symbolize/Symbolize.cpp

579–602

Small amendment: I'd change the snippet above slightly to begin the method body with:

auto InfoOrErr = getOrCreateModuleInfo(ModuleSpecifier);
if (auto Err = InfoOrErr.takeError())
  return Err;
SymbolizableModule *Info = *InfoOrErr;

Which is shorter, follows the convention of most of the rest of the file, and follows https://llvm.org/docs/ProgrammersManual.html#recoverable-errors

[pvellien]

Refactor code

[scott.linder]

This LGTM now, but I would give @ychen and @MaskRay time to take a look.

I'm also curious where the TODO discussed at https://reviews.llvm.org/D63521?id=206255#inline-568633 went, and if it was intentional?

llvm/lib/DebugInfo/Symbolize/Symbolize.cpp

614

Could you add a FIXME: comment here to the effect of "Should this handle COFF specially like getOrCreateModuleInfo(const std::string &) does?"

[pvellien]

Added FIXME

[pvellien]

ping

[scott.linder]

I'm accepting this as there hasn't been any response from others and I don't know who else might be interested, but if anyone has concerns please feel free to review post-commit, and we can revert as necessary.

[dblaikie]

Generally there should be test coverage - otherwise these APIs are likely to be cleaned up as unused, even if the chance of actual bugs in them is small (since they're just simple wrappers).

Perhaps some unit testing would be suitable?

[pvellien]

In D95232#2564264, @dblaikie wrote:

Generally there should be test coverage - otherwise these APIs are likely to be cleaned up as unused, even if the chance of actual bugs in them is small (since they're just simple wrappers).

Perhaps some unit testing would be suitable?

Hi dave, thanks for your comments. I was worried about this thing. But there are no existing tools in llvm that work on object file directly expect there is a usage for one existing API - symbolizeCode. I don't know how it is reliable to add unit tests, I would highly appreciate your thoughts on this. thanks

[dblaikie]

In D95232#2565937, @pvellien wrote:

In D95232#2564264, @dblaikie wrote:

Generally there should be test coverage - otherwise these APIs are likely to be cleaned up as unused, even if the chance of actual bugs in them is small (since they're just simple wrappers).

Perhaps some unit testing would be suitable?

Hi dave, thanks for your comments. I was worried about this thing. But there are no existing tools in llvm that work on object file directly expect there is a usage for one existing API - symbolizeCode.

Sorry, I'm not quite following this last sentence, could you rephrase it?

The first part (" But there are no existing tools in llvm that work on object file directly ") doesn't seem quite right, so far as I'm reading it - llvm-symbolizer, the command line tool, can operate on object files and many of the llvm-symbolizer tests operate on object files. (which also makes me wonder about this change in general - llvm-symbolizer can already work on object files, so why are new APIs required, given the functionality already exists/is used/tested?)

I don't know how it is reliable to add unit tests, I would highly appreciate your thoughts on this. thanks

[pvellien]

In D95232#2566156, @dblaikie wrote:

In D95232#2565937, @pvellien wrote:

In D95232#2564264, @dblaikie wrote:

Generally there should be test coverage - otherwise these APIs are likely to be cleaned up as unused, even if the chance of actual bugs in them is small (since they're just simple wrappers).

Perhaps some unit testing would be suitable?

Hi dave, thanks for your comments. I was worried about this thing. But there are no existing tools in llvm that work on object file directly expect there is a usage for one existing API - symbolizeCode.

Sorry, I'm not quite following this last sentence, could you rephrase it?

The first part (" But there are no existing tools in llvm that work on object file directly ") doesn't seem quite right, so far as I'm reading it - llvm-symbolizer, the command line tool, can operate on object files and many of the llvm-symbolizer tests operate on object files. (which also makes me wonder about this change in general - llvm-symbolizer can already work on object files, so why are new APIs required, given the functionality already exists/is used/tested?)

I don't know how it is reliable to add unit tests, I would highly appreciate your thoughts on this. thanks

Oh sorry, I mean an in-memory object file rather then a on-disk object file. This is similar to this patch : https://reviews.llvm.org/D63521 but it adds overloads for missing functions. Whether it helps? thanks

[MaskRay]

From my reads of the history of this component, I think DebugInfo/Symbolize was extracted from llvm-symbolizer because sanitizer runtime needs it. Later other LLVM internal tools (sanitizer runtime, sancov, sanstats, llvm-xray, etc) use the API as well.
I don't find usage from open-source projects. There could be, but I speculate that if do some refactoring the friction will be small.

Currently the std::string overloads are mainly used. It seems to me that we don't need to std::string overloads. They can likely all switch to the const ObjectFile & overloads.
I will take a stab at cleaning up the call sites.

@pvellien @scott.linder The concern with not testing the new API is that they are otherwise unused (I guess that you may have downstream projects which may adopt them soon) and may be deleted by other contributors as dead code.
If you have some specific use cases, contributing unittests would probably be a good idea.
I'll try refactoring the API, if const std::string& is replaced with const ObjectFile & overloads, then the API will be used by in-tree code and will be less likely deleted as dead code.

[MaskRay]

BTW: symbolizeData is special. Technically symbolizeData does not different things than symbolizeCode. The difference is that it returns DIGlobal which has the size information. Many older binary formats before ELF don't record size information. It is currently only used by hwasan and tsan for diagnostics (D96322).

addr2line does not have a "DATA" symbolization mode. I'd be really curious how you'd use that API.

[dblaikie]

Thanks for taking a look @MaskRay

[MaskRay]

(CC @jhenderson @rnk )

The issues with the const std::string & parameter symbolize* API:

• The LLVMSymbolizer instance needs to construct ObjectFile, which may be a duplicate if the application has an existing ObjectFile instance.
• The file reading error is buried in the API. The application cannot easily tell there is an IO error or incorrect address error and may keep symbolizing more addresses after an IO error. In addition, the user may want to handle the IO error themselves.
• It does magic things (opening an auxiliary file) which may be of security concern for some usage: it constructs a .dsym path for a Mach-O file; it constructs a path from build ID for an ELF file; it constructs a .gnu_debuglink path if the section is present in an ELF file; it constructs a PDB path for a PE file. Personally I'd like the feature to open auxiliary files to be specified explicitly by the user on ELF.

The const ObjectFile & symbolize* does not have the ability to open magic auxiliary files. This is not clear from the API.

If we want to keep just one set of symbolize* overloads and go for const ObjectFile &, we perhaps need to store ObjectFile handles instead of StringRef handles for LLVMSymbolizer's internal maps, and make Expected<SymbolizableModule *> LLVMSymbolizer::getOrCreateModuleInfo(const std::string &ModuleName) public.

I want to check with folks whether whether some refactoring is needed in this area.

---

This can be useful for clients who already have a in-memory object files to symbolize for.

I'd hear more about the use case. For in-memory object files, how do you handle .gnu_debuglink and the build ID stuff. It is possible that you don't want to handle this.

[jhenderson]

I'm not sure if this is what @dblaikie was referring to, but it seems like a good way to test new public-facing APIs would be to write gtest unit tests. I don't think there's any precedent for this for the symbolizer API, so it may not be particularly easy. Refactoring llvm-symbolizer to make use of the new API is probably a good idea, and it may help with the test coverage, but there is a risk that a future refactor beyond that will cause llvm-symbolizer to no longer use the API, and therefore the test coverage is lost.

[pvellien]

In D95232#2566234, @MaskRay wrote:

From my reads of the history of this component, I think DebugInfo/Symbolize was extracted from llvm-symbolizer because sanitizer runtime needs it. Later other LLVM internal tools (sanitizer runtime, sancov, sanstats, llvm-xray, etc) use the API as well.
I don't find usage from open-source projects. There could be, but I speculate that if do some refactoring the friction will be small.

Currently the std::string overloads are mainly used. It seems to me that we don't need to std::string overloads. They can likely all switch to the const ObjectFile & overloads.
I will take a stab at cleaning up the call sites.

@pvellien @scott.linder The concern with not testing the new API is that they are otherwise unused (I guess that you may have downstream projects which may adopt them soon) and may be deleted by other contributors as dead code.
If you have some specific use cases, contributing unittests would probably be a good idea.
I'll try refactoring the API, if const std::string& is replaced with const ObjectFile & overloads, then the API will be used by in-tree code and will be less likely deleted as dead code.

@MaskRay Yes, we planned to use those APIs for the heterogeneous address sanitizer, where we have a device (gpu) object code embedded in a data section of the executable. If we want to symbolize the device object code it would to good to have llvm-symbolizer to symbolize directly on the in-memory instance rather than dumping data to a file and passing the file name to llvm-symbolizer.

[pvellien]

In D95232#2566553, @MaskRay wrote:

(CC @jhenderson @rnk )

The issues with the const std::string & parameter symbolize* API:

• The LLVMSymbolizer instance needs to construct ObjectFile, which may be a duplicate if the application has an existing ObjectFile instance.
• The file reading error is buried in the API. The application cannot easily tell there is an IO error or incorrect address error and may keep symbolizing more addresses after an IO error. In addition, the user may want to handle the IO error themselves.
• It does magic things (opening an auxiliary file) which may be of security concern for some usage: it constructs a .dsym path for a Mach-O file; it constructs a path from build ID for an ELF file; it constructs a .gnu_debuglink path if the section is present in an ELF file; it constructs a PDB path for a PE file. Personally I'd like the feature to open auxiliary files to be specified explicitly by the user on ELF.

The const ObjectFile & symbolize* does not have the ability to open magic auxiliary files. This is not clear from the API.

If we want to keep just one set of symbolize* overloads and go for const ObjectFile &, we perhaps need to store ObjectFile handles instead of StringRef handles for LLVMSymbolizer's internal maps, and make Expected<SymbolizableModule *> LLVMSymbolizer::getOrCreateModuleInfo(const std::string &ModuleName) public.

I want to check with folks whether whether some refactoring is needed in this area.

---

This can be useful for clients who already have a in-memory object files to symbolize for.

I'd hear more about the use case. For in-memory object files, how do you handle .gnu_debuglink and the build ID stuff. It is possible that you don't want to handle this.

we are not handling split dwarf scenario.

[pvellien]

In D95232#2567721, @jhenderson wrote:

I'm not sure if this is what @dblaikie was referring to, but it seems like a good way to test new public-facing APIs would be to write gtest unit tests. I don't think there's any precedent for this for the symbolizer API, so it may not be particularly easy. Refactoring llvm-symbolizer to make use of the new API is probably a good idea, and it may help with the test coverage, but there is a risk that a future refactor beyond that will cause llvm-symbolizer to no longer use the API, and therefore the test coverage is lost.

@jhenderson so if we about to write unit tests for new symbolizer APIs how one should proceed? I would like to get your thoughts since there is no unit tests for Symbolizer

[dblaikie]

In D95232#2566553, @MaskRay wrote:

(CC @jhenderson @rnk )

The issues with the const std::string & parameter symbolize* API:

• The LLVMSymbolizer instance needs to construct ObjectFile, which may be a duplicate if the application has an existing ObjectFile instance.
• The file reading error is buried in the API. The application cannot easily tell there is an IO error or incorrect address error and may keep symbolizing more addresses after an IO error. In addition, the user may want to handle the IO error themselves.
• It does magic things (opening an auxiliary file) which may be of security concern for some usage: it constructs a .dsym path for a Mach-O file; it constructs a path from build ID for an ELF file; it constructs a .gnu_debuglink path if the section is present in an ELF file; it constructs a PDB path for a PE file. Personally I'd like the feature to open auxiliary files to be specified explicitly by the user on ELF.

These ^ are the reasons you're suggesting it would be good to refactor the existing code to take an ObjectFile instead of a std::string file name?

The const ObjectFile & symbolize* does not have the ability to open magic auxiliary files. This is not clear from the API.

This ^ is a limitation of these newly proposed ObjectFile APIs? So they won't be entirely compatible with the existing string-based APIs? So it would be difficult/not possible to refactor the existing code to use these APIs?

If we want to keep just one set of symbolize* overloads and go for const ObjectFile &, we perhaps need to store ObjectFile handles instead of StringRef handles for LLVMSymbolizer's internal maps, and make Expected<SymbolizableModule *> LLVMSymbolizer::getOrCreateModuleInfo(const std::string &ModuleName) public.

What's the current lifetime management of the StringRefs in these internal maps? If they come from multiple different external calls passing in strings, that seems like it'd have lifetime problems (might not be clear the caller needs to keep the underlying string data alive) & would have similar problems with ObjectFile lifetime semantics. But if that's the existing contract/complication, perhaps it's not causing any particular problems.

[pvellien]

In D95232#2572950, @dblaikie wrote:

In D95232#2566553, @MaskRay wrote:

(CC @jhenderson @rnk )

The issues with the const std::string & parameter symbolize* API:

• The LLVMSymbolizer instance needs to construct ObjectFile, which may be a duplicate if the application has an existing ObjectFile instance.
• The file reading error is buried in the API. The application cannot easily tell there is an IO error or incorrect address error and may keep symbolizing more addresses after an IO error. In addition, the user may want to handle the IO error themselves.
• It does magic things (opening an auxiliary file) which may be of security concern for some usage: it constructs a .dsym path for a Mach-O file; it constructs a path from build ID for an ELF file; it constructs a .gnu_debuglink path if the section is present in an ELF file; it constructs a PDB path for a PE file. Personally I'd like the feature to open auxiliary files to be specified explicitly by the user on ELF.

These ^ are the reasons you're suggesting it would be good to refactor the existing code to take an ObjectFile instead of a std::string file name?

Yes

The const ObjectFile & symbolize* does not have the ability to open magic auxiliary files. This is not clear from the API.

This ^ is a limitation of these newly proposed ObjectFile APIs? So they won't be entirely compatible with the existing string-based APIs? So it would be difficult/not possible to refactor the existing code to use these APIs?

I think we can pass the file with debuginfo as an additional parameter as suggested by @MaskRay regarding refactoring all the use-cases within llvm to new APIs I'm not sure how complicated it would be in tools such as symbolizer, objdump etc

If we want to keep just one set of symbolize* overloads and go for const ObjectFile &, we perhaps need to store ObjectFile handles instead of StringRef handles for LLVMSymbolizer's internal maps, and make Expected<SymbolizableModule *> LLVMSymbolizer::getOrCreateModuleInfo(const std::string &ModuleName) public.

What's the current lifetime management of the StringRefs in these internal maps? If they come from multiple different external calls passing in strings, that seems like it'd have lifetime problems (might not be clear the caller needs to keep the underlying string data alive) & would have similar problems with ObjectFile lifetime semantics. But if that's the existing contract/complication, perhaps it's not causing any particular problems.

[jhenderson]

In D95232#2571890, @pvellien wrote:

In D95232#2567721, @jhenderson wrote:

I'm not sure if this is what @dblaikie was referring to, but it seems like a good way to test new public-facing APIs would be to write gtest unit tests. I don't think there's any precedent for this for the symbolizer API, so it may not be particularly easy. Refactoring llvm-symbolizer to make use of the new API is probably a good idea, and it may help with the test coverage, but there is a risk that a future refactor beyond that will cause llvm-symbolizer to no longer use the API, and therefore the test coverage is lost.

@jhenderson so if we about to write unit tests for new symbolizer APIs how one should proceed? I would like to get your thoughts since there is no unit tests for Symbolizer

Sorry for the delay - I've got a very big workload currently and haven't had a chance to get through all review comments from the past week or so. You'd need to write CMakeLists.txt and add a source file for the tests, much like there already is in DebugInfoDWARFTests. You'd then likely want to identify some method to generate test inputs with the required properties. The exact nature of this would depend on what exactly you want to test, but two options might be to reuse the DwarfGenerator code in the DWARF tests, or to use YAML inputs as some other tests for libObject and other places do, to create the object. I can't really give you any more precise details than that, I'm afraid, as I don't know exactly the best way forward without spending time attempting it myself, but I hope these give you some ideas to start with.

llvm/include/llvm/DebugInfo/Symbolize/Symbolize.h

public:
 
   LLVMSymbolizer() = default;
   LLVMSymbolizer(const Options &Opts) : Opts(Opts) {}
 
   ~LLVMSymbolizer() {
     flush();
   }
 
+  // Overloads accepting ObjectFile does not support COFF currently
   Expected<DILineInfo> symbolizeCode(const ObjectFile &Obj,
                                      object::SectionedAddress ModuleOffset);
   Expected<DILineInfo> symbolizeCode(const std::string &ModuleName,
                                      object::SectionedAddress ModuleOffset);
   Expected<DIInliningInfo>
+  symbolizeInlinedCode(const ObjectFile &Obj,
+                       object::SectionedAddress ModuleOffset);
+  Expected<DIInliningInfo>
   symbolizeInlinedCode(const std::string &ModuleName,
                        object::SectionedAddress ModuleOffset);
+
+  Expected<DIGlobal> symbolizeData(const ObjectFile &Obj,
+                                   object::SectionedAddress ModuleOffset);
   Expected<DIGlobal> symbolizeData(const std::string &ModuleName,
                                    object::SectionedAddress ModuleOffset);
   Expected<std::vector<DILocal>>
+  symbolizeFrame(const ObjectFile &Obj, object::SectionedAddress ModuleOffset);
+  Expected<std::vector<DILocal>>
   symbolizeFrame(const std::string &ModuleName,
                  object::SectionedAddress ModuleOffset);
   void flush();
 
   static std::string
   DemangleName(const std::string &Name,
                const SymbolizableModule *DbiModuleDescriptor);
 
 private:
   // Bundles together object file with code/data and object file with
   // corresponding debug info. These objects can be the same.
   using ObjectPair = std::pair<const ObjectFile *, const ObjectFile *>;
 
+  template <typename T>
   Expected<DILineInfo>
-  symbolizeCodeCommon(SymbolizableModule *Info,
+  symbolizeCodeCommon(const T &ModuleSpecifier,
+                      object::SectionedAddress ModuleOffset);
+  template <typename T>
+  Expected<DIInliningInfo>
+  symbolizeInlinedCodeCommon(const T &ModuleSpecifier,
+                             object::SectionedAddress ModuleOffset);
+  template <typename T>
+  Expected<DIGlobal> symbolizeDataCommon(const T &ModuleSpecifier,
+                                         object::SectionedAddress ModuleOffset);
+  template <typename T>
+  Expected<std::vector<DILocal>>
+  symbolizeFrameCommon(const T &ModuleSpecifier,
                        object::SectionedAddress ModuleOffset);
 
   /// Returns a SymbolizableModule or an error if loading debug info failed.
   /// Only one attempt is made to load a module, and errors during loading are
   /// only reported once. Subsequent calls to get module info for a module that
   /// failed to load will return nullptr.
   Expected<SymbolizableModule *>
   getOrCreateModuleInfo(const std::string &ModuleName);
+  Expected<SymbolizableModule *> getOrCreateModuleInfo(const ObjectFile &Obj);
 
   Expected<SymbolizableModule *>
   createModuleInfo(const ObjectFile *Obj,
                    std::unique_ptr<DIContext> Context,
                    StringRef ModuleName);
 
   ObjectFile *lookUpDsymFile(const std::string &Path,
                              const MachOObjectFile *ExeObj,

llvm/lib/DebugInfo/Symbolize/Symbolize.cpp

 #include "llvm/Support/Path.h"
 #include <algorithm>
 #include <cassert>
 #include <cstring>
 
 namespace llvm {
 namespace symbolize {
 
+template <typename T>
 Expected<DILineInfo>
-LLVMSymbolizer::symbolizeCodeCommon(SymbolizableModule *Info,
+LLVMSymbolizer::symbolizeCodeCommon(const T &ModuleSpecifier,
                                     object::SectionedAddress ModuleOffset) {
+
+  auto InfoOrErr = getOrCreateModuleInfo(ModuleSpecifier);
+  if (!InfoOrErr)
+    return InfoOrErr.takeError();
+
+  SymbolizableModule *Info = *InfoOrErr;
+
   // A null module means an error has already been reported. Return an empty
   // result.
   if (!Info)
     return DILineInfo();
 
   // If the user is giving us relative addresses, add the preferred base of the
   // object to the offset before we do the query. It's what DIContext expects.
   if (Opts.RelativeAddresses)
     ModuleOffset.Address += Info->getModulePreferredBase();
 
   DILineInfo LineInfo = Info->symbolizeCode(
       ModuleOffset, DILineInfoSpecifier(Opts.PathStyle, Opts.PrintFunctions),
       Opts.UseSymbolTable);
   if (Opts.Demangle)
     LineInfo.FunctionName = DemangleName(LineInfo.FunctionName, Info);
   return LineInfo;
 }
 
 Expected<DILineInfo>
 LLVMSymbolizer::symbolizeCode(const ObjectFile &Obj,
                               object::SectionedAddress ModuleOffset) {
-  StringRef ModuleName = Obj.getFileName();
-  auto I = Modules.find(ModuleName);
-  if (I != Modules.end())
-    return symbolizeCodeCommon(I->second.get(), ModuleOffset);
-
-  std::unique_ptr<DIContext> Context = DWARFContext::create(Obj);
-  Expected<SymbolizableModule *> InfoOrErr =
-                     createModuleInfo(&Obj, std::move(Context), ModuleName);
-  if (!InfoOrErr)
-    return InfoOrErr.takeError();
-  return symbolizeCodeCommon(*InfoOrErr, ModuleOffset);
+  return symbolizeCodeCommon(Obj, ModuleOffset);
 }
 
 Expected<DILineInfo>
 LLVMSymbolizer::symbolizeCode(const std::string &ModuleName,
                               object::SectionedAddress ModuleOffset) {
-  Expected<SymbolizableModule *> InfoOrErr = getOrCreateModuleInfo(ModuleName);
-  if (!InfoOrErr)
-    return InfoOrErr.takeError();
-  return symbolizeCodeCommon(*InfoOrErr, ModuleOffset);
+  return symbolizeCodeCommon(ModuleName, ModuleOffset);
 }
 
-Expected<DIInliningInfo>
-LLVMSymbolizer::symbolizeInlinedCode(const std::string &ModuleName,
-                                     object::SectionedAddress ModuleOffset) {
-  SymbolizableModule *Info;
-  if (auto InfoOrErr = getOrCreateModuleInfo(ModuleName))
-    Info = InfoOrErr.get();
-  else
+template <typename T>
+Expected<DIInliningInfo> LLVMSymbolizer::symbolizeInlinedCodeCommon(
+    const T &ModuleSpecifier, object::SectionedAddress ModuleOffset) {
+  auto InfoOrErr = getOrCreateModuleInfo(ModuleSpecifier);
+  if (!InfoOrErr)
     return InfoOrErr.takeError();
 
+  SymbolizableModule *Info = *InfoOrErr;
+
   // A null module means an error has already been reported. Return an empty
   // result.
   if (!Info)
     return DIInliningInfo();
 
   // If the user is giving us relative addresses, add the preferred base of the
   // object to the offset before we do the query. It's what DIContext expects.
   if (Opts.RelativeAddresses)
     ModuleOffset.Address += Info->getModulePreferredBase();
 
   DIInliningInfo InlinedContext = Info->symbolizeInlinedCode(
       ModuleOffset, DILineInfoSpecifier(Opts.PathStyle, Opts.PrintFunctions),
       Opts.UseSymbolTable);
   if (Opts.Demangle) {
     for (int i = 0, n = InlinedContext.getNumberOfFrames(); i < n; i++) {
       auto *Frame = InlinedContext.getMutableFrame(i);
       Frame->FunctionName = DemangleName(Frame->FunctionName, Info);
     }
   }
   return InlinedContext;
 }
 
+Expected<DIInliningInfo>
+LLVMSymbolizer::symbolizeInlinedCode(const ObjectFile &Obj,
+                                     object::SectionedAddress ModuleOffset) {
+  return symbolizeInlinedCodeCommon(Obj, ModuleOffset);
+}
+
+Expected<DIInliningInfo>
+LLVMSymbolizer::symbolizeInlinedCode(const std::string &ModuleName,
+                                     object::SectionedAddress ModuleOffset) {
+  return symbolizeInlinedCodeCommon(ModuleName, ModuleOffset);
+}
+
+template <typename T>
 Expected<DIGlobal>
-LLVMSymbolizer::symbolizeData(const std::string &ModuleName,
+LLVMSymbolizer::symbolizeDataCommon(const T &ModuleSpecifier,
                                     object::SectionedAddress ModuleOffset) {
-  SymbolizableModule *Info;
-  if (auto InfoOrErr = getOrCreateModuleInfo(ModuleName))
-    Info = InfoOrErr.get();
-  else
+
+  auto InfoOrErr = getOrCreateModuleInfo(ModuleSpecifier);
+  if (!InfoOrErr)
     return InfoOrErr.takeError();
 
+  SymbolizableModule *Info = *InfoOrErr;
   // A null module means an error has already been reported. Return an empty
   // result.
   if (!Info)
     return DIGlobal();
 
   // If the user is giving us relative addresses, add the preferred base of
   // the object to the offset before we do the query. It's what DIContext
   // expects.
   if (Opts.RelativeAddresses)
     ModuleOffset.Address += Info->getModulePreferredBase();
 
   DIGlobal Global = Info->symbolizeData(ModuleOffset);
   if (Opts.Demangle)
     Global.Name = DemangleName(Global.Name, Info);
   return Global;
 }
 
+Expected<DIGlobal>
+LLVMSymbolizer::symbolizeData(const ObjectFile &Obj,
+                              object::SectionedAddress ModuleOffset) {
+  return symbolizeDataCommon(Obj, ModuleOffset);
+}
+
+Expected<DIGlobal>
+LLVMSymbolizer::symbolizeData(const std::string &ModuleName,
+                              object::SectionedAddress ModuleOffset) {
+  return symbolizeDataCommon(ModuleName, ModuleOffset);
+}
+
+template <typename T>
 Expected<std::vector<DILocal>>
-LLVMSymbolizer::symbolizeFrame(const std::string &ModuleName,
+LLVMSymbolizer::symbolizeFrameCommon(const T &ModuleSpecifier,
                                      object::SectionedAddress ModuleOffset) {
-  SymbolizableModule *Info;
-  if (auto InfoOrErr = getOrCreateModuleInfo(ModuleName))
-    Info = InfoOrErr.get();
-  else
+  auto InfoOrErr = getOrCreateModuleInfo(ModuleSpecifier);
+  if (!InfoOrErr)
     return InfoOrErr.takeError();
 
+  SymbolizableModule *Info = *InfoOrErr;
   // A null module means an error has already been reported. Return an empty
   // result.
   if (!Info)
     return std::vector<DILocal>();
 
   // If the user is giving us relative addresses, add the preferred base of
   // the object to the offset before we do the query. It's what DIContext
   // expects.
   if (Opts.RelativeAddresses)
     ModuleOffset.Address += Info->getModulePreferredBase();
 
   return Info->symbolizeFrame(ModuleOffset);
 }
 
+Expected<std::vector<DILocal>>
+LLVMSymbolizer::symbolizeFrame(const ObjectFile &Obj,
+                               object::SectionedAddress ModuleOffset) {
+  return symbolizeFrameCommon(Obj, ModuleOffset);
+}
+
+Expected<std::vector<DILocal>>
+LLVMSymbolizer::symbolizeFrame(const std::string &ModuleName,
+                               object::SectionedAddress ModuleOffset) {
+  return symbolizeFrameCommon(ModuleName, ModuleOffset);
+}
+
 void LLVMSymbolizer::flush() {
   ObjectForUBPathAndArch.clear();
   BinaryForPath.clear();
   ObjectPairForPathArch.clear();
   Modules.clear();
 }
 
 namespace {
LLVMSymbolizer::getOrCreateModuleInfo(const std::string &ModuleName) {
   auto ObjectsOrErr = getOrCreateObjectPair(BinaryName, ArchName);
   if (!ObjectsOrErr) {
     // Failed to find valid object file.
     Modules.emplace(ModuleName, std::unique_ptr<SymbolizableModule>());
     return ObjectsOrErr.takeError();
   }
   ObjectPair Objects = ObjectsOrErr.get();
 
   std::unique_ptr<DIContext> Context;
   // If this is a COFF object containing PDB info, use a PDBContext to
   // symbolize. Otherwise, use DWARF.
   if (auto CoffObject = dyn_cast<COFFObjectFile>(Objects.first)) {
     const codeview::DebugInfo *DebugInfo;
     StringRef PDBFileName;
     auto EC = CoffObject->getDebugPDBInfo(DebugInfo, PDBFileName);
     if (!EC && DebugInfo != nullptr && !PDBFileName.empty()) {
       using namespace pdb;
       std::unique_ptr<IPDBSession> Session;
 
       PDB_ReaderType ReaderType =
           Opts.UseDIA ? PDB_ReaderType::DIA : PDB_ReaderType::Native;
       if (auto Err = loadDataForEXE(ReaderType, Objects.first->getFileName(),
                                     Session)) {
         Modules.emplace(ModuleName, std::unique_ptr<SymbolizableModule>());
         // Return along the PDB filename to provide more context
         return createFileError(PDBFileName, std::move(Err));
       }
       Context.reset(new PDBContext(*CoffObject, std::move(Session)));
     }
   }
   if (!Context)
     Context = DWARFContext::create(*Objects.second, nullptr, Opts.DWPName);
   return createModuleInfo(Objects.first, std::move(Context), ModuleName);
 }
 
+Expected<SymbolizableModule *>
+LLVMSymbolizer::getOrCreateModuleInfo(const ObjectFile &Obj) {
+  StringRef ObjName = Obj.getFileName();
+  auto I = Modules.find(ObjName);
+  if (I != Modules.end())
+    return I->second.get();
+
+  std::unique_ptr<DIContext> Context = DWARFContext::create(Obj);
+  // FIXME: handle COFF object with PDB info to use PDBContext
+  return createModuleInfo(&Obj, std::move(Context), ObjName);
+}
+
 namespace {
 
 // Undo these various manglings for Win32 extern "C" functions:
 // cdecl       - _foo
 // stdcall     - _foo@12
 // fastcall    - @foo@12
 // vectorcall  - foo@@12
 // These are all different linkage names for 'foo'.