llvm-project/llvm/lib/Object/Object.cpp

241 lines
6.9 KiB
C++
Raw Normal View History

//===- Object.cpp - C bindings to the object file library--------*- C++ -*-===//
//
// The LLVM Compiler Infrastructure
//
// This file is distributed under the University of Illinois Open Source
// License. See LICENSE.TXT for details.
//
//===----------------------------------------------------------------------===//
//
// This file defines the C bindings to the file-format-independent object
// library.
//
//===----------------------------------------------------------------------===//
#include "llvm-c/Object.h"
#include "llvm/ADT/SmallVector.h"
#include "llvm/Object/ObjectFile.h"
using namespace llvm;
using namespace object;
inline OwningBinary<ObjectFile> *unwrap(LLVMObjectFileRef OF) {
return reinterpret_cast<OwningBinary<ObjectFile> *>(OF);
}
inline LLVMObjectFileRef wrap(const OwningBinary<ObjectFile> *OF) {
return reinterpret_cast<LLVMObjectFileRef>(
const_cast<OwningBinary<ObjectFile> *>(OF));
}
inline section_iterator *unwrap(LLVMSectionIteratorRef SI) {
return reinterpret_cast<section_iterator*>(SI);
}
inline LLVMSectionIteratorRef
wrap(const section_iterator *SI) {
return reinterpret_cast<LLVMSectionIteratorRef>
(const_cast<section_iterator*>(SI));
}
inline symbol_iterator *unwrap(LLVMSymbolIteratorRef SI) {
return reinterpret_cast<symbol_iterator*>(SI);
}
inline LLVMSymbolIteratorRef
wrap(const symbol_iterator *SI) {
return reinterpret_cast<LLVMSymbolIteratorRef>
(const_cast<symbol_iterator*>(SI));
}
inline relocation_iterator *unwrap(LLVMRelocationIteratorRef SI) {
return reinterpret_cast<relocation_iterator*>(SI);
}
inline LLVMRelocationIteratorRef
wrap(const relocation_iterator *SI) {
return reinterpret_cast<LLVMRelocationIteratorRef>
(const_cast<relocation_iterator*>(SI));
}
// ObjectFile creation
LLVMObjectFileRef LLVMCreateObjectFile(LLVMMemoryBufferRef MemBuf) {
std::unique_ptr<MemoryBuffer> Buf(unwrap(MemBuf));
Thread Expected<...> up from createMachOObjectFile() to allow llvm-objdump 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
2016-04-07 06:14:09 +08:00
Expected<std::unique_ptr<ObjectFile>> ObjOrErr(
ObjectFile::createObjectFile(Buf->getMemBufferRef()));
std::unique_ptr<ObjectFile> Obj;
Thread Expected<...> up from createMachOObjectFile() to allow llvm-objdump 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
2016-04-07 06:14:09 +08:00
if (!ObjOrErr) {
// TODO: Actually report errors helpfully.
consumeError(ObjOrErr.takeError());
return nullptr;
Thread Expected<...> up from createMachOObjectFile() to allow llvm-objdump 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
2016-04-07 06:14:09 +08:00
}
auto *Ret = new OwningBinary<ObjectFile>(std::move(ObjOrErr.get()), std::move(Buf));
return wrap(Ret);
}
void LLVMDisposeObjectFile(LLVMObjectFileRef ObjectFile) {
delete unwrap(ObjectFile);
}
// ObjectFile Section iterators
LLVMSectionIteratorRef LLVMGetSections(LLVMObjectFileRef OF) {
OwningBinary<ObjectFile> *OB = unwrap(OF);
section_iterator SI = OB->getBinary()->section_begin();
return wrap(new section_iterator(SI));
}
void LLVMDisposeSectionIterator(LLVMSectionIteratorRef SI) {
delete unwrap(SI);
}
LLVMBool LLVMIsSectionIteratorAtEnd(LLVMObjectFileRef OF,
LLVMSectionIteratorRef SI) {
OwningBinary<ObjectFile> *OB = unwrap(OF);
return (*unwrap(SI) == OB->getBinary()->section_end()) ? 1 : 0;
}
void LLVMMoveToNextSection(LLVMSectionIteratorRef SI) {
++(*unwrap(SI));
}
void LLVMMoveToContainingSection(LLVMSectionIteratorRef Sect,
LLVMSymbolIteratorRef Sym) {
Expected<section_iterator> SecOrErr = (*unwrap(Sym))->getSection();
if (!SecOrErr) {
std::string Buf;
raw_string_ostream OS(Buf);
logAllUnhandledErrors(SecOrErr.takeError(), OS);
OS.flush();
report_fatal_error(Buf);
}
*unwrap(Sect) = *SecOrErr;
}
// ObjectFile Symbol iterators
LLVMSymbolIteratorRef LLVMGetSymbols(LLVMObjectFileRef OF) {
OwningBinary<ObjectFile> *OB = unwrap(OF);
symbol_iterator SI = OB->getBinary()->symbol_begin();
return wrap(new symbol_iterator(SI));
}
void LLVMDisposeSymbolIterator(LLVMSymbolIteratorRef SI) {
delete unwrap(SI);
}
LLVMBool LLVMIsSymbolIteratorAtEnd(LLVMObjectFileRef OF,
LLVMSymbolIteratorRef SI) {
OwningBinary<ObjectFile> *OB = unwrap(OF);
return (*unwrap(SI) == OB->getBinary()->symbol_end()) ? 1 : 0;
}
void LLVMMoveToNextSymbol(LLVMSymbolIteratorRef SI) {
++(*unwrap(SI));
}
// SectionRef accessors
const char *LLVMGetSectionName(LLVMSectionIteratorRef SI) {
StringRef ret;
if (std::error_code ec = (*unwrap(SI))->getName(ret))
report_fatal_error(ec.message());
return ret.data();
}
uint64_t LLVMGetSectionSize(LLVMSectionIteratorRef SI) {
return (*unwrap(SI))->getSize();
}
const char *LLVMGetSectionContents(LLVMSectionIteratorRef SI) {
StringRef ret;
if (std::error_code ec = (*unwrap(SI))->getContents(ret))
report_fatal_error(ec.message());
return ret.data();
}
uint64_t LLVMGetSectionAddress(LLVMSectionIteratorRef SI) {
return (*unwrap(SI))->getAddress();
}
LLVMBool LLVMGetSectionContainsSymbol(LLVMSectionIteratorRef SI,
LLVMSymbolIteratorRef Sym) {
return (*unwrap(SI))->containsSymbol(**unwrap(Sym));
}
// Section Relocation iterators
LLVMRelocationIteratorRef LLVMGetRelocations(LLVMSectionIteratorRef Section) {
relocation_iterator SI = (*unwrap(Section))->relocation_begin();
return wrap(new relocation_iterator(SI));
}
void LLVMDisposeRelocationIterator(LLVMRelocationIteratorRef SI) {
delete unwrap(SI);
}
LLVMBool LLVMIsRelocationIteratorAtEnd(LLVMSectionIteratorRef Section,
LLVMRelocationIteratorRef SI) {
return (*unwrap(SI) == (*unwrap(Section))->relocation_end()) ? 1 : 0;
}
void LLVMMoveToNextRelocation(LLVMRelocationIteratorRef SI) {
++(*unwrap(SI));
}
// SymbolRef accessors
const char *LLVMGetSymbolName(LLVMSymbolIteratorRef SI) {
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> Ret = (*unwrap(SI))->getName();
if (!Ret) {
std::string Buf;
raw_string_ostream OS(Buf);
logAllUnhandledErrors(Ret.takeError(), OS);
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
OS.flush();
report_fatal_error(Buf);
}
return Ret->data();
}
uint64_t LLVMGetSymbolAddress(LLVMSymbolIteratorRef SI) {
Expected<uint64_t> Ret = (*unwrap(SI))->getAddress();
if (!Ret) {
std::string Buf;
raw_string_ostream OS(Buf);
logAllUnhandledErrors(Ret.takeError(), OS);
OS.flush();
report_fatal_error(Buf);
}
return *Ret;
}
uint64_t LLVMGetSymbolSize(LLVMSymbolIteratorRef SI) {
return (*unwrap(SI))->getCommonSize();
}
// RelocationRef accessors
uint64_t LLVMGetRelocationOffset(LLVMRelocationIteratorRef RI) {
return (*unwrap(RI))->getOffset();
}
LLVMSymbolIteratorRef LLVMGetRelocationSymbol(LLVMRelocationIteratorRef RI) {
symbol_iterator ret = (*unwrap(RI))->getSymbol();
return wrap(new symbol_iterator(ret));
}
uint64_t LLVMGetRelocationType(LLVMRelocationIteratorRef RI) {
return (*unwrap(RI))->getType();
}
// NOTE: Caller takes ownership of returned string.
const char *LLVMGetRelocationTypeName(LLVMRelocationIteratorRef RI) {
SmallVector<char, 0> ret;
(*unwrap(RI))->getTypeName(ret);
Report fatal error in the case of out of memory This is the second part of recommit of r325224. The previous part was committed in r325426, which deals with C++ memory allocation. Solution for C memory allocation involved functions `llvm::malloc` and similar. This was a fragile solution because it caused ambiguity errors in some cases. In this commit the new functions have names like `llvm::safe_malloc`. The relevant part of original comment is below, updated for new function names. Analysis of fails in the case of out of memory errors can be tricky on Windows. Such error emerges at the point where memory allocation function fails, but manifests itself when null pointer is used. These two points may be distant from each other. Besides, next runs may not exhibit allocation error. In some cases memory is allocated by a call to some of C allocation functions, malloc, calloc and realloc. They are used for interoperability with C code, when allocated object has variable size and when it is necessary to avoid call of constructors. In many calls the result is not checked for null pointer. To simplify checks, new functions are defined in the namespace 'llvm': `safe_malloc`, `safe_calloc` and `safe_realloc`. They behave as corresponding standard functions but produce fatal error if allocation fails. This change replaces the standard functions like 'malloc' in the cases when the result of the allocation function is not checked for null pointer. Finally, there are plain C code, that uses malloc and similar functions. If the result is not checked, assert statement is added. Differential Revision: https://reviews.llvm.org/D43010 llvm-svn: 325551
2018-02-20 13:41:26 +08:00
char *str = static_cast<char*>(safe_malloc(ret.size()));
2018-11-17 09:44:25 +08:00
llvm::copy(ret, str);
return str;
}
// NOTE: Caller takes ownership of returned string.
const char *LLVMGetRelocationValueString(LLVMRelocationIteratorRef RI) {
return strdup("");
}