summaryrefslogtreecommitdiffstats
path: root/llvm/lib/DebugInfo/Symbolize/Symbolize.cpp
Commit message (Collapse)AuthorAgeFilesLines
* Thread Expected<...> up from createMachOObjectFile() to allow llvm-objdump ↵Kevin Enderby2016-04-061-2/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | to produce a real error message Produce the first specific error message for a malformed Mach-O file describing the problem instead of the generic message for object_error::parse_failed of "Invalid data was encountered while parsing the file”.  Many more good error messages will follow after this first one. This is built on Lang Hames’ great work of adding the ’Error' class for structured error handling and threading Error through MachOObjectFile construction. And making createMachOObjectFile return Expected<...> . So to to get the error to the llvm-obdump tool, I changed the stack of these methods to also return Expected<...> : object::ObjectFile::createObjectFile() object::SymbolicFile::createSymbolicFile() object::createBinary() Then finally in ParseInputMachO() in MachODump.cpp the error can be reported and the specific error message can be printed in llvm-objdump and can be seen in the existing test case for the existing malformed binary but with the updated error message. Converting these interfaces to Expected<> from ErrorOr<> does involve touching a number of places. To contain the changes for now use of errorToErrorCode() and errorOrToExpected() are used where the callers are yet to be converted. Also there some were bugs in the existing code that did not deal with the old ErrorOr<> return values. So now with Expected<> since they must be checked and the error handled, I added a TODO and a comment: “// TODO: Actually report errors helpfully” and a call something like consumeError(ObjOrErr.takeError()) so the buggy code will not crash since needed to deal with the Error. Note there is one fix also needed to lld/COFF/InputFiles.cpp that goes along with this that I will commit right after this. So expect lld not to built after this commit and before the next one. llvm-svn: 265606
* Fix Clang-tidy modernize-deprecated-headers warnings in some files; other ↵Eugene Zelenko2016-03-281-10/+19
| | | | | | | | minor fixes. Differential revision: http://reviews.llvm.org/D18469 llvm-svn: 264598
* [Symbolize] Improve the ownership of parsed objects.Alexey Samsonov2015-12-181-46/+45
| | | | | | | | | | | | | | | | | | This code changes the way Symbolize handles parsed binaries: now parsed OwningBinary<Binary> is not broken into (binary, memory buffer) pair, and is just stored as-is in a cache. ObjectFile components of Mach-O universal binaries are also stored explicitly in a separate cache. Additionally, this change: * simplifies the code that parses/caches binaries: it's now done in a single place, not three different functions. * makes flush() method behave as expected, and actually clear the cached parsed binaries and objects. * fixes a dangling pointer issue described in http://reviews.llvm.org/D15638 llvm-svn: 256041
* [LLVMSymbolize] Reduce indentation by using helper function. NFC.Alexey Samsonov2015-11-041-21/+24
| | | | llvm-svn: 252022
* [LLVMSymbolize] Properly propagate object parsing errors from the library.Alexey Samsonov2015-11-041-90/+107
| | | | llvm-svn: 252021
* [LLVMSymbolize] Factor out the logic for printing structs from DIContext. NFC.Alexey Samsonov2015-11-031-61/+14
| | | | | | | | Introduce DIPrinter which takes care of rendering DILineInfo and friends. This allows LLVMSymbolizer class to return a structured data instead of plain std::strings. llvm-svn: 251989
* [LLVMSymbolize] Move demangling away from printing routines. NFC.Alexey Samsonov2015-11-031-28/+33
| | | | | | | | | Make printDILineInfo and friends responsible for just rendering the contents of the structures, demangling should actually be performed earlier, when we have the information about the originating SymbolizableModule at hand. llvm-svn: 251981
* Let the users of LLVMSymbolizer decide whether they want to symbolize ↵Alexey Samsonov2015-10-301-12/+30
| | | | | | | | | | | inlined frames. Introduce LLVMSymbolizer::symbolizeInlinedCode() instead of switching on PrintInlining option passed to the constructor. This will be needed once we retrun structured data (instead of std::string) from LLVMSymbolizer and move printing logic out. llvm-svn: 251675
* [LLVMSymbolize] Move printing the description of a global into a separate ↵Alexey Samsonov2015-10-291-12/+22
| | | | | | function. NFC. llvm-svn: 251669
* [LLVMSymbolize] Move ModuleInfo into a separate class (SymbolizableModule).Alexey Samsonov2015-10-291-218/+21
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: This is mostly NFC. It is a first step in cleaning up LLVMSymbolize library. It removes "ModuleInfo" class which bundles together ObjectFile and its debug info context in favor of: * abstract SymbolizableModule in public headers; * SymbolizableObjectFile subclass in implementation. Additionally, SymbolizableObjectFile is now created via factory, so we can properly detect object parsing error at this stage instead of keeping the broken half-parsed object. As a next step, we would be able to propagate the error all the way back to the library user. Further improvements might include: * factoring out the logic of finding appropriate file with debug info for a given object file, and caching all parsed object files into a separate class [A]. * factoring out DILineInfo rendering [B]. This would make what is now a heavyweight "LLVMSymbolizer" a relatively straightforward class, that calls into [A] to turn filepath into a SymbolizableModule, delegates actual symbolization to concrete SymbolizableModule implementation, and lets [C] render the result. Reviewers: dblaikie, echristo, rafael Subscribers: llvm-commits Differential Revision: http://reviews.llvm.org/D14099 llvm-svn: 251662
* [LLVMSymbolize] Don't use LLVMSymbolizer::Options in ModuleInfo. NFC.Alexey Samsonov2015-10-261-16/+16
| | | | | | | | | LLVMSymbolizer::Options is mostly used in LLVMSymbolizer class anyway. Let's keep their usage restricted to that class, especially given that it's worth to move ModuleInfo to a different header, independent from the symbolizer class. llvm-svn: 251363
* Fix build failure on GCC 4.7 (old libstdc++ doesn't have std::map::emplace).Alexey Samsonov2015-10-261-2/+3
| | | | llvm-svn: 251347
* Remove use of std::map<>::emplace which is not supported on some older ↵David Blaikie2015-10-261-1/+1
| | | | | | versions of libstdc++ llvm-svn: 251346
* [LLVMSymbolize] Use symbol table only if function linkage name was requested.Alexey Samsonov2015-10-261-2/+4
| | | | | | | Now it's enough to just specify -functions=short without additionally providing -use-symbol-table=false. llvm-svn: 251339
* Fix build error by fully qualifying llvm::make_unique.Alexey Samsonov2015-10-261-1/+1
| | | | llvm-svn: 251338
* [LLVMSymbolize] Use std::unique_ptr more extensively to clarify ownership.Alexey Samsonov2015-10-261-11/+12
| | | | llvm-svn: 251336
* Move parts of llvm-symbolizer tool into LLVMSymbolize library.Alexey Samsonov2015-10-261-0/+644
Summary: See http://lists.llvm.org/pipermail/llvm-dev/2015-October/091624.html Reviewers: echristo Subscribers: llvm-commits, aizatsky Differential Revision: http://reviews.llvm.org/D13998 llvm-svn: 251316
OpenPOWER on IntegriCloud