summaryrefslogtreecommitdiffstats
path: root/llvm/lib/DebugInfo/Symbolize/SymbolizableObjectFile.cpp
Commit message (Collapse)AuthorAgeFilesLines
* Recommit r368812 "[llvm/Object] - Convert SectionRef::getName() to return ↵George Rimar2019-08-141-4/+5
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | Expected<>" Changes: no changes. A fix for the clang code will be landed right on top. Original commit message: SectionRef::getName() returns std::error_code now. Returning Expected<> instead has multiple benefits. For example, it forces user to check the error returned. Also Expected<> may keep a valuable string error message, what is more useful than having a error code. (Object\invalid.test was updated to show the new messages printed.) This patch makes a change for all users to switch to Expected<> version. Note: in a few places the error returned was ignored before my changes. In such places I left them ignored. My intention was to convert the interface used, and not to improve and/or the existent users in this patch. (Though I think this is good idea for a follow-ups to revisit such places and either remove consumeError calls or comment each of them to clarify why it is OK to have them). Differential revision: https://reviews.llvm.org/D66089 llvm-svn: 368826
* Revert r368812 "[llvm/Object] - Convert SectionRef::getName() to return ↵George Rimar2019-08-141-5/+4
| | | | | | | | Expected<>" It broke clang BB: http://lab.llvm.org:8011/builders/clang-x86_64-debian-fast/builds/16455 llvm-svn: 368813
* [llvm/Object] - Convert SectionRef::getName() to return Expected<>George Rimar2019-08-141-4/+5
| | | | | | | | | | | | | | | | | | | | | | | SectionRef::getName() returns std::error_code now. Returning Expected<> instead has multiple benefits. For example, it forces user to check the error returned. Also Expected<> may keep a valuable string error message, what is more useful than having a error code. (Object\invalid.test was updated to show the new messages printed.) This patch makes a change for all users to switch to Expected<> version. Note: in a few places the error returned was ignored before my changes. In such places I left them ignored. My intention was to convert the interface used, and not to improve and/or the existent users in this patch. (Though I think this is good idea for a follow-ups to revisit such places and either remove consumeError calls or comment each of them to clarify why it is OK to have them). Differential revision: https://reviews.llvm.org/D66089 llvm-svn: 368812
* Switch LLVM to use 64-bit offsets (2/5)Igor Kudrin2019-08-061-4/+2
| | | | | | | | | This updates all libraries and tools in LLVM Core to use 64-bit offsets which directly or indirectly come to DataExtractor. Differential Revision: https://reviews.llvm.org/D65638 llvm-svn: 368014
* Silence ubsan after r367926.Peter Collingbourne2019-08-061-0/+1
| | | | | | | | | | | | Fixes e.g. http://lab.llvm.org:8011/builders/sanitizer-x86_64-linux-bootstrap-ubsan/builds/14273 We can't left shift here because left shifting of a negative number is UB. The same doesn't apply to unsigned arithmetic, but switching to unsigned doesn't appear to stop ubsan from complaining, so we need to mask out the high bits. llvm-svn: 367959
* llvm-symbolizer: Untag addresses in object files by default.Peter Collingbourne2019-08-051-4/+12
| | | | | | | | | | Any addresses that we pass to llvm-symbolizer are going to be untagged, while any HWASAN instrumented globals are going to be tagged in the symbol table. Therefore we need to untag the addresses before using them. Differential Revision: https://reviews.llvm.org/D65769 llvm-svn: 367926
* Teach the symbolizer lib symbolize objects directly.Yuanfang Chen2019-07-081-2/+2
| | | | | | | | | | | | | | Currently, the symbolizer lib can only symbolize a file on disk. This patch teaches the symbolizer lib to symbolize objects. llvm-objdump needs this to support archive disassembly with source info. https://bugs.llvm.org/show_bug.cgi?id=41871 Reviewed by: jhenderson, grimar, MaskRay Differential Revision: https://reviews.llvm.org/D63521 llvm-svn: 365376
* llvm-symbolizer: Add a FRAME command.Peter Collingbourne2019-06-241-0/+8
| | | | | | | | | | | | | | | | | | | This command prints a description of the referenced function's stack frame. For each formal parameter and local variable, the tool prints: - function name - variable name - file/line of declaration - FP-relative variable location (if available) - size in bytes - HWASAN tag offset This information will be used by the HWASAN runtime to identify local variables in UAR reports. Differential Revision: https://reviews.llvm.org/D63468 llvm-svn: 364225
* Symbolize: Remove dead code. NFCI.Peter Collingbourne2019-06-131-11/+5
| | | | | | | | | | The only caller of SymbolizableObjectFile::create passes a non-null DebugInfoContext and asserts that they do so. Move the assert into SymbolizableObjectFile::create and remove null checks. Differential Revision: https://reviews.llvm.org/D63298 llvm-svn: 363334
* Recommit [Object] Change object::SectionRef::getContents() to return ↵Fangrui Song2019-05-161-4/+4
| | | | | | | | | | | | Expected<StringRef> r360876 didn't fix 2 call sites in clang. Expected<ArrayRef<uint8_t>> may be better but use Expected<StringRef> for now. Follow-up of D61781. llvm-svn: 360892
* Revert r360876 "[Object] Change object::SectionRef::getContents() to return ↵Hans Wennborg2019-05-161-4/+4
| | | | | | | | | | | | Expected<StringRef>" It broke the Clang build, see llvm-commits thread. > Expected<ArrayRef<uint8_t>> may be better but use Expected<StringRef> for now. > > Follow-up of D61781. llvm-svn: 360878
* [Object] Change object::SectionRef::getContents() to return Expected<StringRef>Fangrui Song2019-05-161-4/+4
| | | | | | | | Expected<ArrayRef<uint8_t>> may be better but use Expected<StringRef> for now. Follow-up of D61781. llvm-svn: 360876
* [llvm-symbolizer] Fix section index at the end of a sectionFangrui Song2019-04-201-2/+1
| | | | | | | | This is very minor issue. The returned section index is only used by DWARFDebugLine as an llvm::upper_bound input and the use case shouldn't cause any behavioral change. llvm-svn: 358814
* [Symbolize] Uniquify sorted vector<pair<SymbolDesc, StringRef>>Fangrui Song2019-04-061-7/+16
| | | | llvm-svn: 357833
* [Symbolize] Replace map<SymbolDesc, StringRef> with sorted vectorFangrui Song2019-04-051-8/+14
| | | | llvm-svn: 357758
* [Symbolize] Keep SymbolDescs with the same address and improve ↵Fangrui Song2019-04-041-1/+4
| | | | | | | | getNameFromSymbolTable heuristic I'll follow up with better heuristics or tests. llvm-svn: 357683
* [DebugInfo] follow up for "add SectionedAddress to DebugInfo interfaces"Alexey Lapshin2019-03-231-0/+26
| | | | | | | | | | | | | | | | | | | | | | | [Symbolizer] Add getModuleSectionIndexForAddress() helper routine The https://reviews.llvm.org/D58194 patch changed symbolizer interface. Particularily it requires not only Address but SectionIndex also. Note object::SectionedAddress parameter: Expected<DILineInfo> symbolizeCode(const std::string &ModuleName, object::SectionedAddress ModuleOffset, StringRef DWPName = ""); There are callers of symbolizer which do not know particular section index. That patch creates getModuleSectionIndexForAddress() routine which will detect section index for the specified address. Thus if caller set ModuleOffset.SectionIndex into object::SectionedAddress::UndefSection state then symbolizer would detect section index using getModuleSectionIndexForAddress routine. Differential Revision: https://reviews.llvm.org/D58848 llvm-svn: 356829
* [DebugInfo] add SectionedAddress to DebugInfo interfaces.Alexey Lapshin2019-02-271-9/+12
| | | | | | | | | | | | | | | | | That patch is the fix for https://bugs.llvm.org/show_bug.cgi?id=40703 "wrong line number info for obj file compiled with -ffunction-sections" bug. The problem happened with only .o files. If object file contains several .text sections then line number information showed incorrectly. The reason for this is that DwarfLineTable could not detect section which corresponds to specified address(because address is the local to the section). And as the result it could not select proper sequence in the line table. The fix is to pass SectionIndex with the address. So that it would be possible to differentiate addresses from various sections. With this fix llvm-objdump shows correct line numbers for disassembled code. Differential review: https://reviews.llvm.org/D58194 llvm-svn: 354972
* [symbolizer] Avoid collecting symbols belonging to invalid sections.Matt Davis2019-02-141-0/+5
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: llvm-symbolizer would originally report symbols that belonged to an invalid object file section. Specifically the case where: `*Symbol.getSection() == ObjFile.section_end()` This patch prevents the Symbolizer from collecting symbols that belong to invalid sections. The test (from PR40591) introduces a case where two symbols have address 0, one symbol is defined, 'foo', and the other is not defined, 'bar'. This patch will cause the Symbolizer to keep 'foo' and ignore 'bar'. As a side note, the logic for adding symbols to the Symbolizer's store (`SymbolizableObjectFile::addSymbol`) replaces symbols with the same <address, size> pair. At some point that logic should be revisited as in the aforementioned case, 'bar' was overwriting 'foo' in the Symbolizer's store, and 'foo' was forgotten. This fixes PR40591 Reviewers: jhenderson, rupprecht Reviewed By: rupprecht Subscribers: hiraditya, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D58146 llvm-svn: 354083
* Update the file headers across all of the LLVM projects in the monorepoChandler Carruth2019-01-191-4/+3
| | | | | | | | | | | | | | | | | to reflect the new license. We understand that people may be surprised that we're moving the header entirely to discuss the new license. We checked this carefully with the Foundation's lawyer and we believe this is the correct approach. Essentially, all code in the project is now made available by the LLVM project under our new license, so you will see that the license headers include that license only. Some of our contributors have contributed code under our old license, and accordingly, we have retained a copy of our old license notice in the top-level files in each project and repository. llvm-svn: 351636
* Remove trailing spaceFangrui Song2018-07-301-1/+1
| | | | | | sed -Ei 's/[[:space:]]+$//' include/**/*.{def,h,td} lib/**/*.{cpp,h} llvm-svn: 338293
* Move Object format code to lib/BinaryFormat.Zachary Turner2017-06-071-1/+1
| | | | | | | | | | | | This creates a new library called BinaryFormat that has all of the headers from llvm/Support containing structure and layout definitions for various types of binary formats like dwarf, coff, elf, etc as well as the code for identifying a file from its magic. Differential Revision: https://reviews.llvm.org/D33843 llvm-svn: 304864
* [MC] Fix some Clang-tidy modernize and Include What You Use warnings in ↵Eugene Zelenko2017-02-091-11/+24
| | | | | | | | SubtargetFeature; other minor fixes (NFC). Same changes in files affected by reduced SubtargetFeature.h dependencies. llvm-svn: 294548
* Prune RelocVisitor.h include to avoid including COFF.h from MCJIT.hReid Kleckner2016-07-061-0/+1
| | | | | | | This helps to mitigate the conflict between COFF.h and winnt.h, which is PR28399. llvm-svn: 274637
* Thread Expected<...> up from libObject’s getSymbolAddress() for symbols to ↵Kevin Enderby2016-06-241-3/+3
| | | | | | | | | | | | | | | | | | | | | allow a good error message to be produced. This is nearly the last libObject interface that used ErrorOr and the last one that appears in llvm/include/llvm/Object/MachO.h . For Mach-O objects this is just a clean up because it’s version of getSymbolAddress() can’t return an error. I will leave it to the experts on COFF and ELF to actually add meaning full error messages in their tests if they wish. And also leave it to these experts to change the last two ErrorOr interfaces in llvm/include/llvm/Object/ObjectFile.h for createCOFFObjectFile() and createELFObjectFile() if they wish. Since there are no test cases for COFF and ELF error cases with respect to getSymbolAddress() in the test suite this is no functional change (NFC). llvm-svn: 273701
* Thread Expected<...> up from libObject’s getType() for symbols to allow ↵Kevin Enderby2016-05-021-3/+3
| | | | | | | | | | | | | | | | | | | | | | llvm-objdump to produce a good error message. Produce another specific error message for a malformed Mach-O file when a symbol’s section index is more than the number of sections. The existing test case in test/Object/macho-invalid.test for macho-invalid-section-index-getSectionRawName now reports the error with the message indicating that a symbol at a specific index has a bad section index and that bad section index value. Again converting interfaces to Expected<> from ErrorOr<> does involve touching a number of places. Where the existing code reported the error with a string message or an error code it was converted to do the same. 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(NameOrErr.takeError()) so the buggy code will not crash since needed to deal with the Error. llvm-svn: 268298
* Thread Expected<...> up from libObject’s getName() for symbols to allow ↵Kevin Enderby2016-04-201-3/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | llvm-objdump to produce a good error message. Produce another specific error message for a malformed Mach-O file when a symbol’s string index is past the end of the string table. The existing test case in test/Object/macho-invalid.test for macho-invalid-symbol-name-past-eof now reports the error with the message indicating that a symbol at a specific index has a bad sting index and that bad string index value. Again converting interfaces to Expected<> from ErrorOr<> does involve touching a number of places. Where the existing code reported the error with a string message or an error code it was converted to do the same. There is some code for this that could be factored into a routine but I would like to leave that for the code owners post-commit to do as they want for handling an llvm::Error. An example of how this could be done is shown in the diff in lib/ExecutionEngine/RuntimeDyld/RuntimeDyldImpl.h which had a Check() routine already for std::error_code so I added one like it for llvm::Error . 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(NameOrErr.takeError()) so the buggy code will not crash since needed to deal with the Error. Note there fixes needed to lld 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: 266919
* Fix a crash in running llvm-objdump -t with an invalid Mach-O file alreadyKevin Enderby2016-03-231-1/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | in the test suite. While this is not really an interesting tool and option to run on a Mach-O file to show the symbol table in a generic libObject format it shouldn’t crash. The reason for the crash was in MachOObjectFile::getSymbolType() when it was calling MachOObjectFile::getSymbolSection() without checking its return value for the error case. What makes this fix require a fair bit of diffs is that the method getSymbolType() is in the class ObjectFile defined without an ErrorOr<> so I needed to add that all the sub classes.  And all of the uses needed to be updated and the return value needed to be checked for the error case. The MachOObjectFile version of getSymbolType() “can” get an error in trying to come up with the libObject’s internal SymbolRef::Type when the Mach-O symbol symbol type is an N_SECT type because the code is trying to select from the SymbolRef::ST_Data or SymbolRef::ST_Function values for the SymbolRef::Type. And it needs the Mach-O section to use isData() and isBSS to determine if it will return SymbolRef::ST_Data. One other possible fix I considered is to simply return SymbolRef::ST_Other when MachOObjectFile::getSymbolSection() returned an error. But since in the past when I did such changes that “ate an error in the libObject code” I was asked instead to push the error out of the libObject code I chose not to implement the fix this way. As currently written both the COFF and ELF versions of getSymbolType() can’t get an error. But if isReservedSectionNumber() wanted to check for the two known negative values rather than allowing all negative values or the code wanted to add the same check as in getSymbolAddress() to use getSection() and check for the error then these versions of getSymbolType() could return errors. At the end of the day the error printed now is the generic “Invalid data was encountered while parsing the file” for object_error::parse_failed. In the future when we thread Lang’s new TypedError for recoverable error handling though libObject this will improve. And where the added // Diagnostic(… comment is, it would be changed to produce and error message like “bad section index (42) for symbol at index 8” for this case. llvm-svn: 264187
* [Symbolizer] Don't use PE symbol tables to override PDB symbolsReid Kleckner2015-11-131-2/+13
| | | | | | | | | | | | | | | | | | | | | Summary: PE files are stripped by default, and only contain the names of exported symbols. The actual reason that we bother to do this override by default is actually due to a quirk of the way -gline-tables-only is implemented, so I phrased the check as "if we are symbolizing from dwarf, do the symtab override". This fixes lots of Windows ASan tests that I broke in r250582. Reviewers: samsonov Subscribers: llvm-commits Differential Revision: http://reviews.llvm.org/D14594 llvm-svn: 253051
* [LLVMSymbolize] Simplify SymbolizableObjectFile::symbolizeInlinedCode(). NFC.Alexey Samsonov2015-10-301-17/+9
| | | | llvm-svn: 251672
* [LLVMSymbolize] Move printing the description of a global into a separate ↵Alexey Samsonov2015-10-291-5/+5
| | | | | | function. NFC. llvm-svn: 251669
* [LLVMSymbolize] Move ModuleInfo into a separate class (SymbolizableModule).Alexey Samsonov2015-10-291-0/+251
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
OpenPOWER on IntegriCloud