[PATCH] D95232: Symbolizer - Teach symbolizer to work directly on object file.

[praveen velliengiri via Phabricator via llvm-commits]

pvellien added a comment.

In D95232#2566553 <https://reviews.llvm.org/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.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D95232/new/

https://reviews.llvm.org/D95232