summaryrefslogtreecommitdiffstats
path: root/llvm/lib/Object
Commit message (Collapse)AuthorAgeFilesLines
...
* Don't pass a Reloc::Model to MC.Rafael Espindola2016-05-181-1/+1
| | | | | | | | | | | | MC only needs to know if the output is PIC or not. It never has to decide about creating GOTs and PLTs for example. The only thing that MC itself uses this information for is expanding "macros" in sparc and mips. The rest I am pretty sure could be moved to CodeGen. This is a cleanup and isolates the code from future changes to Reloc::Model. llvm-svn: 269909
* [Object] Move isNotObjectErrorInvalidFileType out of header.Lang Hames2016-05-171-0/+18
| | | | llvm-svn: 269848
* Change llvm-objdump, llvm-nm and llvm-size when reporting an object file errorKevin Enderby2016-05-171-3/+8
| | | | | | | | | | | | | | | | | | | | | when the object is in an archive to use something like libx.a(foo.o) as part of the error message. Also changed llvm-objdump and llvm-size to be like llvm-nm and ignore non-object files in archives and not produce any error message. To do this Archive::Child::getAsBinary() was changed from ErrorOr<...> to Expected<...> then that was threaded up to its users. Converting this interface to Expected<> from ErrorOr<> does involve touching a number of places. To contain the changes for now the use of errorToErrorCode() is still used in one place yet to be fully converted. Again 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 comments for those. llvm-svn: 269784
* Return a StringRef from getSection.Rafael Espindola2016-05-111-1/+1
| | | | | | This is similar to how getName is handled. llvm-svn: 269218
* Fix bug where temporary file would be left behind every time an archive was ↵Rafael Espindola2016-05-091-1/+15
| | | | | | | | | | | | | | | | | | | updated. When updating an existing archive, llvm-ar opens the old archive into a `MemoryBuffer`, does its thing, and writes the results to a temporary file. That file is then renamed to the original archive filename, thus replacing it with the updated contents. However, on Windows at least, what would happen is that the `MemoryBuffer` for the old archive would actually be an mmap'ed view of the file, so when it came time to do the rename via Win32's `ReplaceFile`, it would succeed but would be unable to fully replace the file since there would still be a handle open on it; instead, the old version got renamed to a random temporary name and left behind. Patch by Cameron! llvm-svn: 268916
* Change GenericBinaryError to no longer include a FileName, which is then notKevin Enderby2016-05-062-32/+30
| | | | | | | | | | | | | | | | | | part of the error message. As the caller is the one that needs to add the name of where the "object file" comes from to the error message as the object file could be in an archive, or coming from a slice of a Mach-O universal file or a buffer created by a JIT. In the cases of a Mach-O universal file the architecture name may or may not also need to be printed which is up to the tool code. For example if the tool code is only selecting the host architecture slice then that architecture name is never printed. This patch is the change to the libObject code and there will be follow on commits for changes to the code for each tool. llvm-svn: 268789
* Object: Fix two -Wpessimizing-move warnings after r268694Justin Bogner2016-05-051-5/+4
| | | | llvm-svn: 268697
* Fix window bots failures due to r268694 - Cleanup and refactor of ↵Kevin Enderby2016-05-051-1/+1
| | | | | | malformedError() in lib/Object/MachOObjectFile.cpp . llvm-svn: 268696
* Cleanup and refactor of malformedError() in lib/Object/MachOObjectFile.cpp .Kevin Enderby2016-05-051-71/+41
| | | | | | No functional change. llvm-svn: 268694
* Clean up the specific error message for a malformed Mach-O files with bad ↵Kevin Enderby2016-05-052-14/+12
| | | | | | | | | | | | | | | | | | | | | segment load commands. The existing test case in test/Object/macho-invalid.test for macho-invalid-too-small-segment-load-command has a cmdsize of 55, while being too small also it is not a multiple of 4. So when that check is added this test case will produce a different error. So I constructed a new test case that will trigger the intended error. I also changed the error message to be consistent with the other malformed Mach-O file error messages which prints the load command index. I also removed both object_error::macho_load_segment_too_small and object_error::macho_load_segment_too_many_sections from Object/Error.h as they are not needed and can just use object_error::parse_failed and let the error message string distinguish the specific error. llvm-svn: 268652
* Produce another specific error message for a malformed Mach-O file when a loadKevin Enderby2016-05-032-7/+7
| | | | | | | | | | | | | | | | command has a size less than 8 bytes. I think the existing test case in test/Object/macho-invalid.test for macho64-invalid-too-small-load-command was trying to test for this but that test case triggered a different error given how it was constructed. So I constructed a new test case that would trigger this specific error. I also changed the error message to be consistent with the other malformed Mach-O file error messages. I also removed object_error::macho_small_load_command from Object/Error.h as it is not needed and can just use object_error::parse_failed and let the error message string distinguish the error. llvm-svn: 268463
* Produce another specific error message for a malformed Mach-O file when a loadKevin Enderby2016-05-031-2/+10
| | | | | | | | | | | | | | command other than the first one is past the end of the load commands. This is like the test case in test/Object/macho-invalid.test for macho64-invalid-incomplete-load-command but it is the second load command that is past the end of all the load commands instead of the first. The code in the constructor for MachOObjectFile that loops over the load commands used getNextLoadCommandInfo() which was not producing a good error message. So that was fixed and a test case was added. llvm-svn: 268403
* [lib/Object] Make this assertion more useful.Davide Italiano2016-05-031-3/+2
| | | | llvm-svn: 268367
* Don't try to create thin bsd archives.Rafael Espindola2016-05-021-0/+3
| | | | | | Not such variant has been specified yet. llvm-svn: 268305
* Thread Expected<...> up from libObject’s getType() for symbols to allow ↵Kevin Enderby2016-05-024-15/+24
| | | | | | | | | | | | | | | | | | | | | | 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
* Expose a getFullName for thin archive members.Rafael Espindola2016-05-021-10/+18
| | | | | | It will be used in lld. llvm-svn: 268226
* MachO: remove weird ARM/Thumb interface from MachOObjectFileTim Northover2016-04-221-58/+6
| | | | | | | | | | | | | | | | Only one consumer (llvm-objdump) actually cared about the fact that there were two triples. Others were actively working around the fact that the Triple returned by getArch might have been invalid. As for llvm-objdump, it needs to be acutely aware of both Triples anyway, so being generic in the exposed API is no benefit. Also rename the version of getArch returning a Triple. Users were having to pass an unwanted nullptr to disambiguate the two, which was nasty. The only functional change here is that armv7m and armv7em object files no longer crash llvm-objdump. llvm-svn: 267249
* Clean the API for CollectAsmUndefinedRefs, taking a Triple and a String ↵Mehdi Amini2016-04-221-5/+3
| | | | | | | InlineAsm instead of a Module (NFC) From: Mehdi Amini <mehdi.amini@apple.com> llvm-svn: 267106
* IRObjectFile, clang-format fixup for r267104Mehdi Amini2016-04-221-4/+5
| | | | | From: Mehdi Amini <mehdi.amini@apple.com> llvm-svn: 267105
* Use std::move on the enum to insert it into the pair to please MSVCMehdi Amini2016-04-221-1/+1
| | | | | | | | (I have no idea why is it needed) Fixup for r267103 From: Mehdi Amini <mehdi.amini@apple.com> llvm-svn: 267104
* Refactor IRObjectFile, extract a static CollectAsmUndefinedRefs() method to ↵Mehdi Amini2016-04-221-4/+15
| | | | | | | | | parse inline assembly (NFC) I plan to call this from ThinLTOCodeGenerator. From: Mehdi Amini <mehdi.amini@apple.com> llvm-svn: 267103
* [ThinLTO] Remove unused/incomplete lazy summary reading support (NFC)Teresa Johnson2016-04-221-20/+2
| | | | | | | | | | | | | | This removes the interfaces added (and not yet complete) to support lazy reading of summaries. This support is not expected to be needed since we are moving to a model where the full index is only being traversed in the thin link step, instead of the back ends. (The second part of this that I plan to do next is remove the GlobalValueInfo from the ModuleSummaryIndex - it was mostly needed to support lazy parsing of summaries. The index can instead reference the summary structures directly.) llvm-svn: 267097
* Fix a typo in an error message. Caught by Sean Silva!Kevin Enderby2016-04-211-1/+1
| | | | llvm-svn: 267056
* hange the variable name big_size to BigSize. Caught by Rafael Espíndola!Kevin Enderby2016-04-211-14/+14
| | | | llvm-svn: 267043
* Fix compilation error in r266919.Evgeniy Stepanov2016-04-201-1/+1
| | | | | | | lib/Object/MachOObjectFile.cpp:53:44: error: moving a temporary object prevents copy elision [-Werror,-Wpessimizing-move] return malformedError(Obj.getFileName(), std::move(Msg.str()), ECOverride); llvm-svn: 266930
* Thread Expected<...> up from libObject’s getName() for symbols to allow ↵Kevin Enderby2016-04-204-14/+34
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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
* Replace a loop with a for-each loop. No behavior change.Nico Weber2016-04-201-2/+1
| | | | llvm-svn: 266903
* [NFC] Header cleanupMehdi Amini2016-04-182-2/+0
| | | | | | | | | | | | | | Removed some unused headers, replaced some headers with forward class declarations. Found using simple scripts like this one: clear && ack --cpp -l '#include "llvm/ADT/IndexedMap.h"' | xargs grep -L 'IndexedMap[<]' | xargs grep -n --color=auto 'IndexedMap' Patch by Eugene Kosov <claprix@yandex.ru> Differential Revision: http://reviews.llvm.org/D19219 From: Mehdi Amini <mehdi.amini@apple.com> llvm-svn: 266595
* Start to add real error messages for malformed Mach-O files.Kevin Enderby2016-04-131-2/+17
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | And update the existing test cases in test/Object/macho-invalid.test to use llvm-objdump with the -macho option to produce these error messages and stop producing the generic "Invalid data was encountered while parsing the file" message. Working from the beginning of the file, if the mach header is too large for the size of the file and then if the load commands that follow extend past the end of the file these two errors now generate correct error messages. Both of these have existing test cases in test/Object/macho-invalid.test . But the first with macho-invalid-header it will never trigger the error message "mach header extends past the end of the file" using any of the llvm tools as they all use identify_magic() which rejects files with the correct magic number that are too small in size. So I tested this by hacking that code and seeing the error message down in parseHeader() really does happen. So in case there is ever code in llvm that directly calls createMachOObjectFile() this error message will be correctly produced. The second error message of "load commands extends past the end of the file" is triggered by a number of existing tests cases in test/Object/macho-invalid.test . Also other tests trigger different error messages now like "ilocalsym plus nlocalsym in LC_DYSYMTAB load command extends past the end of the symbol table". There are two existing test cases that still get the "Invalid data was encountered ..." error messages that I will tackle next. But they will involve a bit of pluming an Expect<...> up through the call stack and I want to do those as separate changes. FYI, for those test cases that were trying to test specific errors that now get different errors I’ll fix those in follow on changes and create new test cases for those so they test the error they were meant to test. llvm-svn: 266248
* Thread Expected<...> up from createMachOObjectFile() to allow llvm-objdump ↵Kevin Enderby2016-04-069-36/+49
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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
* Object: Correctly read thin archives containing absolute paths.Peter Collingbourne2016-03-311-3/+8
| | | | | | Differential Revision: http://reviews.llvm.org/D18666 llvm-svn: 265065
* Remove else after returnDavid Blaikie2016-03-281-4/+3
| | | | llvm-svn: 264599
* [Support] Switch to RAII helper for error-as-out-parameter idiom.Lang Hames2016-03-251-2/+2
| | | | | | As discussed on the llvm-commits thread for r264467. llvm-svn: 264479
* [Object] Make createMachOObjectFile return Expected<...> rather thanLang Hames2016-03-253-12/+9
| | | | | | ErrorOr<...>. llvm-svn: 264473
* [Object] Make MachOObjectFile's constructor private, provide a static createLang Hames2016-03-251-29/+26
| | | | | | | | | | method instead. This is not quite a named constructor: Construction may fail, and MachOObjectFiles are usually passed by unique_ptr anyway, so create returns an Expected<std::unique_ptr<MachOObjectFile>>. llvm-svn: 264469
* [Object] Start threading Error through MachOObjectFile construction.Lang Hames2016-03-252-92/+151
| | | | llvm-svn: 264425
* Fix a crash in running llvm-objdump -t with an invalid Mach-O file alreadyKevin Enderby2016-03-232-4/+11
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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
* [COFF] Refactor section alignment calculationDavid Majnemer2016-03-171-1/+1
| | | | | | | Section alignment isn't completely trivial, let it live in one place so that we may reuse it in LLVM. llvm-svn: 263722
* [ThinLTO] Renaming of function index to module summary index (NFC)Teresa Johnson2016-03-152-36/+38
| | | | | | | | | | | | | | | (Resubmitting after fixing missing file issue) With the changes in r263275, there are now more than just functions in the summary. Completed the renaming of data structures (started in r263275) to reflect the wider scope. In particular, changed the FunctionIndex* data structures to ModuleIndex*, and renamed related variables and comments. Also renamed the files to reflect the changes. A companion clang patch will immediately succeed this patch to reflect this renaming. llvm-svn: 263513
* Revert "[ThinLTO] Renaming of function index to module summary index (NFC)"Teresa Johnson2016-03-142-38/+36
| | | | | | This reverts commit r263490. Missed a file. llvm-svn: 263493
* [ThinLTO] Renaming of function index to module summary index (NFC)Teresa Johnson2016-03-142-36/+38
| | | | | | | | | | | | | With the changes in r263275, there are now more than just functions in the summary. Completed the renaming of data structures (started in r263275) to reflect the wider scope. In particular, changed the FunctionIndex* data structures to ModuleIndex*, and renamed related variables and comments. Also renamed the files to reflect the changes. A companion clang patch will immediately succeed this patch to reflect this renaming. llvm-svn: 263490
* [ThinLTO] Support for reference graph in per-module and combined summary.Teresa Johnson2016-03-111-3/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: This patch adds support for including a full reference graph including call graph edges and other GV references in the summary. The reference graph edges can be used to make importing decisions without materializing any source modules, can be used in the plugin to make file staging decisions for distributed build systems, and is expected to have other uses. The call graph edges are recorded in each function summary in the bitcode via a list of <CalleeValueIds, StaticCount> tuples when no PGO data exists, or <CalleeValueId, StaticCount, ProfileCount> pairs when there is PGO, where the ValueId can be mapped to the function GUID via the ValueSymbolTable. In the function index in memory, the call graph edges reference the target via the CalleeGUID instead of the CalleeValueId. The reference graph edges are recorded in each summary record with a list of referenced value IDs, which can be mapped to value GUID via the ValueSymbolTable. Addtionally, a new summary record type is added to record references from global variable initializers. A number of bitcode records and data structures have been renamed to reflect the newly expanded scope of the summary beyond functions. More cleanup will follow. Reviewers: joker.eph, davidxl Subscribers: joker.eph, llvm-commits Differential Revision: http://reviews.llvm.org/D17212 llvm-svn: 263275
* [lanai] Add ELF enum value and relocations.Jacques Pienaar2016-03-011-0/+7
| | | | | | | | | | Add ELF enum value and relocations for Lanai backed. General Lanai backend discussion on llvm-dev thread "[RFC] Lanai backend" (http://lists.llvm.org/pipermail/llvm-dev/2016-February/095118.html). Differential Revision: http://reviews.llvm.org/D17008 llvm-svn: 262394
* Move ObjectYAML code to a new library.Rafael Espindola2016-03-013-1333/+0
| | | | | | | It is only ever used by obj2yaml and yaml2obj. No point in linking it everywhere. llvm-svn: 262368
* Rename embedded bitcode section in MachOSteven Wu2016-02-294-8/+17
| | | | | | | | | | | | | | Summary: Rename the section embeds bitcode from ".llvmbc,.llvmbc" to "__LLVM,__bitcode". The new name matches MachO section naming convention. Reviewers: rafael, pcc Subscribers: davide, llvm-commits, joker.eph Differential Revision: http://reviews.llvm.org/D17388 llvm-svn: 262245
* IRObject: Mark extern_weak as weak.Rafael Espindola2016-02-291-1/+2
| | | | llvm-svn: 262222
* Represent the dynamic table itself with a DynRegionInfo.Rafael Espindola2016-02-171-2/+0
| | | | | | | | | | | | The dynamic table is also an array of a fixed structure, so it can be represented with a DynReginoInfo. No major functionality change. The extra error checking is covered by existing tests with a broken dynamic program header. Idea extracted from r260488. I did the extra cleanups. llvm-svn: 261107
* Simplify users of StringRef::{l,r}trim (NFC)Vedant Kumar2016-02-161-9/+8
| | | | | | | r260925 introduced a version of the *trim methods which is preferable when trimming a single kind of character. Update all users in llvm. llvm-svn: 260926
* Use copy initialization.Rafael Espindola2016-02-111-2/+2
| | | | | | We can do it since getMemBuffer returns a unique_ptr. llvm-svn: 260576
* Move MCTargetAsmParser.h to llvm/MC/MCParser where it belongs.Benjamin Kramer2016-01-271-1/+1
| | | | llvm-svn: 258917
OpenPOWER on IntegriCloud