maxjhandsome
/
llvm-project
forked from OSchip/llvm-project
1
0
Fork 0
Code Issues Pull Requests Packages Releases Wiki Activity
llvm-project/llvm/lib/DebugInfo/Symbolize/SymbolizableObjectFile.cpp

272 lines
10 KiB
C++
Raw Normal View History

[MC] Fix some Clang-tidy modernize and Include What You Use warnings in SubtargetFeature; other minor fixes (NFC). Same changes in files affected by reduced SubtargetFeature.h dependencies. llvm-svn: 294548
2017-02-09 09:09:54 +08:00
//===- SymbolizableObjectFile.cpp -----------------------------------------===//
[LLVMSymbolize] Move ModuleInfo into a separate class (SymbolizableModule). 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
2015-10-30 06:21:37 +08:00
//
// The LLVM Compiler Infrastructure
//
// This file is distributed under the University of Illinois Open Source
// License. See LICENSE.TXT for details.
//
//===----------------------------------------------------------------------===//
//
// Implementation of SymbolizableObjectFile class.
//
//===----------------------------------------------------------------------===//
#include "SymbolizableObjectFile.h"
[MC] Fix some Clang-tidy modernize and Include What You Use warnings in SubtargetFeature; other minor fixes (NFC). Same changes in files affected by reduced SubtargetFeature.h dependencies. llvm-svn: 294548
2017-02-09 09:09:54 +08:00
#include "llvm/ADT/STLExtras.h"
#include "llvm/ADT/StringRef.h"
#include "llvm/ADT/Triple.h"
Move Object format code to lib/BinaryFormat. 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
2017-06-07 11:48:56 +08:00
#include "llvm/BinaryFormat/COFF.h"
[MC] Fix some Clang-tidy modernize and Include What You Use warnings in SubtargetFeature; other minor fixes (NFC). Same changes in files affected by reduced SubtargetFeature.h dependencies. llvm-svn: 294548
2017-02-09 09:09:54 +08:00
#include "llvm/DebugInfo/DWARF/DWARFContext.h"
#include "llvm/DebugInfo/Symbolize/SymbolizableModule.h"
Prune RelocVisitor.h include to avoid including COFF.h from MCJIT.h This helps to mitigate the conflict between COFF.h and winnt.h, which is PR28399. llvm-svn: 274637
2016-07-07 00:56:42 +08:00
#include "llvm/Object/COFF.h"
[MC] Fix some Clang-tidy modernize and Include What You Use warnings in SubtargetFeature; other minor fixes (NFC). Same changes in files affected by reduced SubtargetFeature.h dependencies. llvm-svn: 294548
2017-02-09 09:09:54 +08:00
#include "llvm/Object/ObjectFile.h"
[LLVMSymbolize] Move ModuleInfo into a separate class (SymbolizableModule). 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
2015-10-30 06:21:37 +08:00
#include "llvm/Object/SymbolSize.h"
[MC] Fix some Clang-tidy modernize and Include What You Use warnings in SubtargetFeature; other minor fixes (NFC). Same changes in files affected by reduced SubtargetFeature.h dependencies. llvm-svn: 294548
2017-02-09 09:09:54 +08:00
#include "llvm/Support/Casting.h"
[LLVMSymbolize] Move ModuleInfo into a separate class (SymbolizableModule). 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
2015-10-30 06:21:37 +08:00
#include "llvm/Support/DataExtractor.h"
[MC] Fix some Clang-tidy modernize and Include What You Use warnings in SubtargetFeature; other minor fixes (NFC). Same changes in files affected by reduced SubtargetFeature.h dependencies. llvm-svn: 294548
2017-02-09 09:09:54 +08:00
#include "llvm/Support/Error.h"
#include <algorithm>
#include <cstdint>
#include <memory>
#include <string>
#include <system_error>
#include <utility>
#include <vector>
[LLVMSymbolize] Move ModuleInfo into a separate class (SymbolizableModule). 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
2015-10-30 06:21:37 +08:00
[MC] Fix some Clang-tidy modernize and Include What You Use warnings in SubtargetFeature; other minor fixes (NFC). Same changes in files affected by reduced SubtargetFeature.h dependencies. llvm-svn: 294548
2017-02-09 09:09:54 +08:00
using namespace llvm;
[LLVMSymbolize] Move ModuleInfo into a separate class (SymbolizableModule). 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
2015-10-30 06:21:37 +08:00
using namespace object;
[MC] Fix some Clang-tidy modernize and Include What You Use warnings in SubtargetFeature; other minor fixes (NFC). Same changes in files affected by reduced SubtargetFeature.h dependencies. llvm-svn: 294548
2017-02-09 09:09:54 +08:00
using namespace symbolize;
[LLVMSymbolize] Move ModuleInfo into a separate class (SymbolizableModule). 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
2015-10-30 06:21:37 +08:00
static DILineInfoSpecifier
getDILineInfoSpecifier(FunctionNameKind FNKind) {
return DILineInfoSpecifier(
DILineInfoSpecifier::FileLineInfoKind::AbsoluteFilePath, FNKind);
}
ErrorOr<std::unique_ptr<SymbolizableObjectFile>>
SymbolizableObjectFile::create(object::ObjectFile *Obj,
std::unique_ptr<DIContext> DICtx) {
std::unique_ptr<SymbolizableObjectFile> res(
new SymbolizableObjectFile(Obj, std::move(DICtx)));
std::unique_ptr<DataExtractor> OpdExtractor;
uint64_t OpdAddress = 0;
// Find the .opd (function descriptor) section if any, for big-endian
// PowerPC64 ELF.
if (Obj->getArch() == Triple::ppc64) {
for (section_iterator Section : Obj->sections()) {
StringRef Name;
StringRef Data;
if (auto EC = Section->getName(Name))
return EC;
if (Name == ".opd") {
if (auto EC = Section->getContents(Data))
return EC;
OpdExtractor.reset(new DataExtractor(Data, Obj->isLittleEndian(),
Obj->getBytesInAddress()));
OpdAddress = Section->getAddress();
break;
}
}
}
std::vector<std::pair<SymbolRef, uint64_t>> Symbols =
computeSymbolSizes(*Obj);
for (auto &P : Symbols)
res->addSymbol(P.first, P.second, OpdExtractor.get(), OpdAddress);
// If this is a COFF object and we didn't find any symbols, try the export
// table.
if (Symbols.empty()) {
if (auto *CoffObj = dyn_cast<COFFObjectFile>(Obj))
if (auto EC = res->addCoffExportSymbols(CoffObj))
return EC;
}
return std::move(res);
}
SymbolizableObjectFile::SymbolizableObjectFile(ObjectFile *Obj,
std::unique_ptr<DIContext> DICtx)
: Module(Obj), DebugInfoContext(std::move(DICtx)) {}
namespace {
[MC] Fix some Clang-tidy modernize and Include What You Use warnings in SubtargetFeature; other minor fixes (NFC). Same changes in files affected by reduced SubtargetFeature.h dependencies. llvm-svn: 294548
2017-02-09 09:09:54 +08:00
[LLVMSymbolize] Move ModuleInfo into a separate class (SymbolizableModule). 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
2015-10-30 06:21:37 +08:00
struct OffsetNamePair {
uint32_t Offset;
StringRef Name;
[MC] Fix some Clang-tidy modernize and Include What You Use warnings in SubtargetFeature; other minor fixes (NFC). Same changes in files affected by reduced SubtargetFeature.h dependencies. llvm-svn: 294548
2017-02-09 09:09:54 +08:00
[LLVMSymbolize] Move ModuleInfo into a separate class (SymbolizableModule). 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
2015-10-30 06:21:37 +08:00
bool operator<(const OffsetNamePair &R) const {
return Offset < R.Offset;
}
};
[MC] Fix some Clang-tidy modernize and Include What You Use warnings in SubtargetFeature; other minor fixes (NFC). Same changes in files affected by reduced SubtargetFeature.h dependencies. llvm-svn: 294548
2017-02-09 09:09:54 +08:00
} // end anonymous namespace
[LLVMSymbolize] Move ModuleInfo into a separate class (SymbolizableModule). 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
2015-10-30 06:21:37 +08:00
std::error_code SymbolizableObjectFile::addCoffExportSymbols(
const COFFObjectFile *CoffObj) {
// Get all export names and offsets.
std::vector<OffsetNamePair> ExportSyms;
for (const ExportDirectoryEntryRef &Ref : CoffObj->export_directories()) {
StringRef Name;
uint32_t Offset;
if (auto EC = Ref.getSymbolName(Name))
return EC;
if (auto EC = Ref.getExportRVA(Offset))
return EC;
ExportSyms.push_back(OffsetNamePair{Offset, Name});
}
if (ExportSyms.empty())
return std::error_code();
// Sort by ascending offset.
array_pod_sort(ExportSyms.begin(), ExportSyms.end());
// Approximate the symbol sizes by assuming they run to the next symbol.
// FIXME: This assumes all exports are functions.
uint64_t ImageBase = CoffObj->getImageBase();
for (auto I = ExportSyms.begin(), E = ExportSyms.end(); I != E; ++I) {
OffsetNamePair &Export = *I;
// FIXME: The last export has a one byte size now.
uint32_t NextOffset = I != E ? I->Offset : Export.Offset + 1;
uint64_t SymbolStart = ImageBase + Export.Offset;
uint64_t SymbolSize = NextOffset - Export.Offset;
SymbolDesc SD = {SymbolStart, SymbolSize};
Functions.insert(std::make_pair(SD, Export.Name));
}
return std::error_code();
}
std::error_code SymbolizableObjectFile::addSymbol(const SymbolRef &Symbol,
uint64_t SymbolSize,
DataExtractor *OpdExtractor,
uint64_t OpdAddress) {
Thread Expected<...> up from libObject’s getType() for symbols to allow 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
2016-05-03 04:28:12 +08:00
Expected<SymbolRef::Type> SymbolTypeOrErr = Symbol.getType();
if (!SymbolTypeOrErr)
return errorToErrorCode(SymbolTypeOrErr.takeError());
Fix a crash in running llvm-objdump -t with an invalid Mach-O file already 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
2016-03-24 04:27:00 +08:00
SymbolRef::Type SymbolType = *SymbolTypeOrErr;
[LLVMSymbolize] Move ModuleInfo into a separate class (SymbolizableModule). 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
2015-10-30 06:21:37 +08:00
if (SymbolType != SymbolRef::ST_Function && SymbolType != SymbolRef::ST_Data)
return std::error_code();
Thread Expected<...> up from libObject’s getSymbolAddress() for symbols to 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
2016-06-25 02:24:42 +08:00
Expected<uint64_t> SymbolAddressOrErr = Symbol.getAddress();
if (!SymbolAddressOrErr)
return errorToErrorCode(SymbolAddressOrErr.takeError());
[LLVMSymbolize] Move ModuleInfo into a separate class (SymbolizableModule). 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
2015-10-30 06:21:37 +08:00
uint64_t SymbolAddress = *SymbolAddressOrErr;
if (OpdExtractor) {
// For big-endian PowerPC64 ELF, symbols in the .opd section refer to
// function descriptors. The first word of the descriptor is a pointer to
// the function's code.
// For the purposes of symbolization, pretend the symbol's address is that
// of the function's code, not the descriptor.
uint64_t OpdOffset = SymbolAddress - OpdAddress;
uint32_t OpdOffset32 = OpdOffset;
if (OpdOffset == OpdOffset32 &&
OpdExtractor->isValidOffsetForAddress(OpdOffset32))
SymbolAddress = OpdExtractor->getAddress(&OpdOffset32);
}
Thread Expected<...> up from libObject’s getName() for symbols to allow 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
2016-04-21 05:24:34 +08:00
Expected<StringRef> SymbolNameOrErr = Symbol.getName();
if (!SymbolNameOrErr)
return errorToErrorCode(SymbolNameOrErr.takeError());
[LLVMSymbolize] Move ModuleInfo into a separate class (SymbolizableModule). 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
2015-10-30 06:21:37 +08:00
StringRef SymbolName = *SymbolNameOrErr;
// Mach-O symbol table names have leading underscore, skip it.
[MC] Fix some Clang-tidy modernize and Include What You Use warnings in SubtargetFeature; other minor fixes (NFC). Same changes in files affected by reduced SubtargetFeature.h dependencies. llvm-svn: 294548
2017-02-09 09:09:54 +08:00
if (Module->isMachO() && !SymbolName.empty() && SymbolName[0] == '_')
[LLVMSymbolize] Move ModuleInfo into a separate class (SymbolizableModule). 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
2015-10-30 06:21:37 +08:00
SymbolName = SymbolName.drop_front();
// FIXME: If a function has alias, there are two entries in symbol table
// with same address size. Make sure we choose the correct one.
auto &M = SymbolType == SymbolRef::ST_Function ? Functions : Objects;
SymbolDesc SD = { SymbolAddress, SymbolSize };
M.insert(std::make_pair(SD, SymbolName));
return std::error_code();
}
// Return true if this is a 32-bit x86 PE COFF module.
bool SymbolizableObjectFile::isWin32Module() const {
auto *CoffObject = dyn_cast<COFFObjectFile>(Module);
return CoffObject && CoffObject->getMachine() == COFF::IMAGE_FILE_MACHINE_I386;
}
uint64_t SymbolizableObjectFile::getModulePreferredBase() const {
if (auto *CoffObject = dyn_cast<COFFObjectFile>(Module))
return CoffObject->getImageBase();
return 0;
}
bool SymbolizableObjectFile::getNameFromSymbolTable(SymbolRef::Type Type,
uint64_t Address,
std::string &Name,
uint64_t &Addr,
uint64_t &Size) const {
const auto &SymbolMap = Type == SymbolRef::ST_Function ? Functions : Objects;
if (SymbolMap.empty())
return false;
SymbolDesc SD = { Address, Address };
auto SymbolIterator = SymbolMap.upper_bound(SD);
if (SymbolIterator == SymbolMap.begin())
return false;
--SymbolIterator;
if (SymbolIterator->first.Size != 0 &&
SymbolIterator->first.Addr + SymbolIterator->first.Size <= Address)
return false;
Name = SymbolIterator->second.str();
Addr = SymbolIterator->first.Addr;
Size = SymbolIterator->first.Size;
return true;
}
[Symbolizer] Don't use PE symbol tables to override PDB symbols 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
2015-11-14 01:00:36 +08:00
bool SymbolizableObjectFile::shouldOverrideWithSymbolTable(
FunctionNameKind FNKind, bool UseSymbolTable) const {
// When DWARF is used with -gline-tables-only / -gmlt, the symbol table gives
// better answers for linkage names than the DIContext. Otherwise, we are
// probably using PEs and PDBs, and we shouldn't do the override. PE files
// generally only contain the names of exported symbols.
return FNKind == FunctionNameKind::LinkageName && UseSymbolTable &&
isa<DWARFContext>(DebugInfoContext.get());
}
[LLVMSymbolize] Move ModuleInfo into a separate class (SymbolizableModule). 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
2015-10-30 06:21:37 +08:00
DILineInfo SymbolizableObjectFile::symbolizeCode(uint64_t ModuleOffset,
FunctionNameKind FNKind,
bool UseSymbolTable) const {
DILineInfo LineInfo;
if (DebugInfoContext) {
LineInfo = DebugInfoContext->getLineInfoForAddress(
ModuleOffset, getDILineInfoSpecifier(FNKind));
}
// Override function name from symbol table if necessary.
[Symbolizer] Don't use PE symbol tables to override PDB symbols 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
2015-11-14 01:00:36 +08:00
if (shouldOverrideWithSymbolTable(FNKind, UseSymbolTable)) {
[LLVMSymbolize] Move ModuleInfo into a separate class (SymbolizableModule). 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
2015-10-30 06:21:37 +08:00
std::string FunctionName;
uint64_t Start, Size;
if (getNameFromSymbolTable(SymbolRef::ST_Function, ModuleOffset,
FunctionName, Start, Size)) {
LineInfo.FunctionName = FunctionName;
}
}
return LineInfo;
}
DIInliningInfo SymbolizableObjectFile::symbolizeInlinedCode(
uint64_t ModuleOffset, FunctionNameKind FNKind, bool UseSymbolTable) const {
DIInliningInfo InlinedContext;
if (DebugInfoContext)
InlinedContext = DebugInfoContext->getInliningInfoForAddress(
ModuleOffset, getDILineInfoSpecifier(FNKind));
// Make sure there is at least one frame in context.
if (InlinedContext.getNumberOfFrames() == 0)
InlinedContext.addFrame(DILineInfo());
// Override the function name in lower frame with name from symbol table.
[Symbolizer] Don't use PE symbol tables to override PDB symbols 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
2015-11-14 01:00:36 +08:00
if (shouldOverrideWithSymbolTable(FNKind, UseSymbolTable)) {
[LLVMSymbolize] Simplify SymbolizableObjectFile::symbolizeInlinedCode(). NFC. llvm-svn: 251672
2015-10-30 08:02:55 +08:00
std::string FunctionName;
uint64_t Start, Size;
if (getNameFromSymbolTable(SymbolRef::ST_Function, ModuleOffset,
FunctionName, Start, Size)) {
InlinedContext.getMutableFrame(InlinedContext.getNumberOfFrames() - 1)
->FunctionName = FunctionName;
[LLVMSymbolize] Move ModuleInfo into a separate class (SymbolizableModule). 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
2015-10-30 06:21:37 +08:00
}
}
[LLVMSymbolize] Simplify SymbolizableObjectFile::symbolizeInlinedCode(). NFC. llvm-svn: 251672
2015-10-30 08:02:55 +08:00
return InlinedContext;
[LLVMSymbolize] Move ModuleInfo into a separate class (SymbolizableModule). 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
2015-10-30 06:21:37 +08:00
}
[LLVMSymbolize] Move printing the description of a global into a separate function. NFC. llvm-svn: 251669
2015-10-30 07:49:19 +08:00
DIGlobal SymbolizableObjectFile::symbolizeData(uint64_t ModuleOffset) const {
DIGlobal Res;
getNameFromSymbolTable(SymbolRef::ST_Data, ModuleOffset, Res.Name, Res.Start,
Res.Size);
return Res;
[LLVMSymbolize] Move ModuleInfo into a separate class (SymbolizableModule). 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
2015-10-30 06:21:37 +08:00
}