summaryrefslogtreecommitdiffstats
path: root/lld/lib/ReaderWriter
Commit message (Collapse)AuthorAgeFilesLines
...
* Convert normalized file to atoms methods to new error handling. NFC.Pete Cooper2016-03-304-119/+128
| | | | | | | This converts almost all of the error handling in atom creation to llvm::Error instead of std::error_code. llvm-svn: 264968
* Convert lld file writing to llvm::Error. NFC.Pete Cooper2016-03-305-37/+38
| | | | | | | This converts the writeFile method, as well as some of the ones it calls in the normalized binary file writer and yaml writer. llvm-svn: 264961
* Remove useless unreachable. Switch coverage already gives us this. NFCPete Cooper2016-03-301-1/+0
| | | | llvm-svn: 264945
* Convert file handle* methods to llvm::Error instead of std::error_code. NFC.Pete Cooper2016-03-301-8/+8
| | | | | | | This updates most of the file handling methods in the linking context and resolver to use the new API. llvm-svn: 264924
* Convert lld Pass::runOnFile to llvm::Error from std::error_code. NFC.Pete Cooper2016-03-308-20/+20
| | | | | | | Pretty mechanical change here. Just replacing all the std::error_code() with llvm::Error() and make_dynamic_error_code with make_error<GenericError> llvm-svn: 264917
* Change getReferenceInfo/getPairReferenceInfo to use new Error handling. NFC.Pete Cooper2016-03-306-215/+209
| | | | | | | | | | | | Adds a GenericError class to lld/Core which can carry a string. This is analygous to the dynamic_error we currently use in lld/Core. Use this GenericError instead of make_dynamic_error_code. Also, provide an implemention of GenericError::convertToErrorCode which for now converts it in to the dynamic_error_code we used to have. This will go away once all the APIs are converted. llvm-svn: 264910
* Remove dead flags.Rui Ueyama2016-03-284-64/+8
| | | | | | | | | | | searchArchivesToOverrideTentativeDefinitions and searchSharedLibrariesToOverrideTentativeDefinitions are always false. For the dead flags, we have a fairly large amount of code which is never be executed. http://reviews.llvm.org/D17791 llvm-svn: 264653
* Use None to construct an empty ArrayRef. NFC.Pete Cooper2016-03-241-1/+1
| | | | | | Suggested by David Blaikie in response to r264234. llvm-svn: 264311
* Avoid UB when creating empty atoms. NFC.Pete Cooper2016-03-241-0/+2
| | | | | | | | | The stack-size.yaml test had an empty atom content array. This is legal, but asking a BumpPtrAllocator for 0 sized data may not be legal. Instead just avoid requesting any data when we can just return an empty ArrayRef instead. llvm-svn: 264234
* Avoid UB deref of nullptr to reference. NFC.Pete Cooper2016-03-241-0/+5
| | | | | | | | | Its possible for file to have no entry atom which means that there is no atom to check for being a thumb function. Instead just skip the thumb check and set the entry address to 0, which matches the current behaviour of getting a default initialised int from a map. llvm-svn: 264233
* Use a memcpy to avoid unaligned store UB.Pete Cooper2016-03-241-6/+9
| | | | | | | On a 32-bit output, we may write LC_MAIN (which contains a uint64_t) to an unaligned address. This changes it to use a memcpy instead which is UB safe. llvm-svn: 264232
* Use unaligned read to fix UB. NFC.Pete Cooper2016-03-241-3/+4
| | | | | | | | | | | We were casting a potentially unaligned pointer to uint32_t and dereferencing. As the pointer ultimately comes from the object file, there's no way to guarantee alignment, so use the little32_t read instead. Also, little32_t knows about endianness, so in theory this may have broken on big endian machines. llvm-svn: 264231
* Parsed alignment should be a power of 2.Pete Cooper2016-03-242-2/+28
| | | | | | | | | | The .o path always makes sure to store a power of 2 value in the Section alignment. However, the YAML code didn't verify this. Added verification and updated all the tests which had a 3 but meant to have 2^3. llvm-svn: 264228
* Fix more cases of UB from allocating 0 sized data. NFC.Pete Cooper2016-03-236-17/+25
| | | | | | | | | | | | The size of a section can be zero, even when it contains atoms, so long as all of the atoms are also size 0. In this case we were allocating space for a 0 sized buffer. Changed this to only allocate when we need the space, but also cleaned up all the code to use MutableArrayRef instead of uint8_t* so its much much safer as we get bounds checking on all of our section creation logic. llvm-svn: 264204
* Use a memcpy to avoid unaligned store UB.Pete Cooper2016-03-231-5/+8
| | | | | | | On a 32-bit output, we may write LC_SOURCE_VERSION (which contains a uint64_t) to an unaligned address. This changes it to use a memcpy instead which is UB safe. llvm-svn: 264202
* Add the needed lld change for r264187 in llvm.Kevin Enderby2016-03-231-1/+4
| | | | | | | Sorry had this fixed in my check out but failed mention it in my commit message for r264187. llvm-svn: 264188
* Copy MachO struct to temporary to avoid unaligned load UB.Pete Cooper2016-03-231-4/+4
| | | | | | | We were already copying this data to a temporary for endian swaps. Now we just always copy it, but still only do the endian swaps when needed. llvm-svn: 264172
* Move empty atom check to target independent code. NFC.Pete Cooper2016-03-222-5/+5
| | | | | | | | | | Turns out that checking only x86 for empty atoms to fix UBSan then requires the same code in the other targets too. Better to just check this in the main run loop instead of in each target. Should be NFC, other than fixing UBSan failures. llvm-svn: 264116
* Avoid memcpy from nullptr. NFC.Pete Cooper2016-03-221-0/+5
| | | | | | | | | | This was caught by the UBSan bot. When the atom has no size, we would issue a memcpy with size0 and a nullptr for the source. Also, this code should never have references inside an empty atom so add an assert for that while we're here. llvm-svn: 264115
* Don't memcpy from a null source. Found by UBSanPete Cooper2016-03-221-0/+2
| | | | llvm-svn: 264114
* More MSVC bot appeasement. Explicitly define rvalue methods on SortKey.Pete Cooper2016-03-221-0/+19
| | | | | | | | | | | | | | OwningAtomPtr does not have OwningAtomPtr(OwningAtomPtr&) or the equivalent operator= as we only want to use rvalue references in it. SortKey didn't like this on MSVC as it was synthesizing SortKey(SortKey&) and trying to use the OwningAtomPtr(OwningAtomPtr&) method which was private an unimplemented. Now we explicitly have the methods on SortKey so hopefully the bot will be happier. llvm-svn: 264077
* Use owning pointers instead of raw pointers for Atom's to fix leaks.Pete Cooper2016-03-2216-86/+240
| | | | | | | | | | | | | | | | | | | | | | | | This is a re-commit of r264022 with a fix for MSVC. The issue there was that the code was running DefinedAtom::~Atom() for some value and instead needed to cast to Atom before running ~Atom. Original commit message follows. Currently each File contains an BumpPtrAllocator in which Atom's are allocated. Some Atom's contain data structures like std::vector which leak as we don't run ~Atom when they are BumpPtrAllocate'd. Now each File actually owns its Atom's using an OwningAtomPtr. This is analygous to std::unique_ptr and may be replaced by it if possible. An Atom can therefore only be owned by a single File, so the Resolver now moves them from one File to another. The MachOLinkingContext owns the File's and so clears all the Atom's in ~MachOLinkingContext, then delete's all the File's. This makes sure all Atom's have been destructed before any of the BumpPtrAllocator's in which they run have gone away. Should hopefully fix the remaining leaks. Will keep an eye on the bots to make sure. llvm-svn: 264067
* DenseMap resize() is now named reserved(), adapt the call sitesMehdi Amini2016-03-221-2/+2
| | | | | From: Mehdi Amini <mehdi.amini@apple.com> llvm-svn: 264028
* Revert "Use owning pointers instead of raw pointers for Atom's to fix leaks."Pete Cooper2016-03-2216-240/+86
| | | | | | | | | | | | This reverts commit r264022. This breaks the Window's bots which don't like that i'm calling ~Atom when the this pointer is a sublcass of Atom. Reverting for now until I try find a better fix. I tried using std::unique_ptr with a custom deleter as a quick fix, but it didn't work well in the YAML parser. llvm-svn: 264023
* Use owning pointers instead of raw pointers for Atom's to fix leaks.Pete Cooper2016-03-2216-86/+240
| | | | | | | | | | | | | | | | | | | | Currently each File contains an BumpPtrAllocator in which Atom's are allocated. Some Atom's contain data structures like std::vector which leak as we don't run ~Atom when they are BumpPtrAllocate'd. Now each File actually owns its Atom's using an OwningAtomPtr. This is analygous to std::unique_ptr and may be replaced by it if possible. An Atom can therefore only be owned by a single File, so the Resolver now moves them from one File to another. The MachOLinkingContext owns the File's and so clears all the Atom's in ~MachOLinkingContext, then delete's all the File's. This makes sure all Atom's have been destructed before any of the BumpPtrAllocator's in which they run have gone away. Should hopefully fix the remaining leaks. Will keep an eye on the bots to make sure. llvm-svn: 264022
* Move ownership of Pass File's to the MachoLinkingContext.Pete Cooper2016-03-216-12/+14
| | | | | | | | | In trying to fix the leaks in the MachO lld codebase, we need to have a better model for file and atom ownership. Having the context own everything seems like the simplest model, so change all the passes to allocate File's on the context instead of owning files as a member. llvm-svn: 264004
* Always pass an allocator to YAMLTraits.Pete Cooper2016-03-171-4/+9
| | | | | | | | | | | The YAML traits new's when not passed an allocator to parse data. For atom types, this is a leak as we don't destruct atoms. For the File here, we do actually destruct File's so that single case of not using an allocator will be fine. Should fix a bunch more leaks. llvm-svn: 263680
* Use allocator in YAML code to avoid leaking atom content.Pete Cooper2016-03-161-4/+6
| | | | | | | | | | In lld we allocate atoms on an allocator and so don't run their destructors. This means we also shouldn't allocate memory inside them without that also being on an allocator. Reviewed by Lang Hames and Rafael Espindola. llvm-svn: 263677
* Fix EHFrame processing to add implicit references when needed.Pete Cooper2016-03-156-32/+252
| | | | | | | | | | | | | | | | | The current code for processCIE and processFDE returns out if it sees any references. The problem with this is that some references could be explicit in the binary, while others are implicit as they can be inferred from the content of the EHFrame itself. This change walks the references we have against the references we need, and verifies that all explicit references are in the correct place, and generates any missing implicit ones. Reviewed by Lang Hames and Nick Kledzik. Differential Revision: http://reviews.llvm.org/D15439 llvm-svn: 263590
* Use C++11 initializers for data members.Rui Ueyama2016-03-021-11/+1
| | | | | | http://reviews.llvm.org/D17793 llvm-svn: 262501
* Remove dead code.Rui Ueyama2016-03-021-2/+0
| | | | llvm-svn: 262436
* Remove remaining files of Core.Rui Ueyama2016-03-022-51/+0
| | | | llvm-svn: 262435
* Make a few utility functions file-scoped.Rui Ueyama2016-03-011-1/+1
| | | | | | | makeErrorFile and parseMemberFiles are now used only in DarwinLdDriver.cpp. This patch moves them to that file. llvm-svn: 262423
* Fix BUILD_SHARED_LIBS build.Rafael Espindola2016-03-011-0/+1
| | | | llvm-svn: 262345
* Remove dead code for ELF.Rui Ueyama2016-02-281-45/+0
| | | | | | The preload feature was buggy that we had disabled it even for ELF. llvm-svn: 262194
* Remove remaining code for COFF.Rui Ueyama2016-02-281-9/+0
| | | | llvm-svn: 262193
* Delete more COFF and ELF bits from the old linker.Rafael Espindola2016-02-281-7/+2
| | | | llvm-svn: 262184
* Delete more ELF bits from the old linker.Rafael Espindola2016-02-281-47/+1
| | | | llvm-svn: 262181
* Remove a few bits of elf from the old linker.Rafael Espindola2016-02-281-2/+0
| | | | llvm-svn: 262164
* Delete the old script parser.Rafael Espindola2016-02-282-2896/+0
| | | | | | It was ELF specific. llvm-svn: 262163
* Remove the old ELF linker.Rafael Espindola2016-02-28122-20756/+0
| | | | | | I think it is clear by now that the new linker is viable. llvm-svn: 262158
* Use ArrayRef instead of deep copies of CompactUnwindEntries. NFC.Pete Cooper2016-02-101-10/+7
| | | | | | | | | We have a vector of all of the compact unwind entries anyway, and its live as long as we need it to be. So instead of copying from that vector to another, just take references to the range of the original vector we need for each compact unwind page. llvm-svn: 260437
* Silence MSVC warning about falling off the end of a function after a fully ↵Reid Kleckner2016-02-101-0/+1
| | | | | | covered switch llvm-svn: 260417
* Use __nl_symbol_ptr instead of __got in the stubs pass on x86 archs.Pete Cooper2016-02-097-5/+24
| | | | | | | | | | The non lazy atoms generated in the stubs pass use an image cache to hold all of the pointers. On arm archs, this is the __got section, but on x86 archs it should be __nl_symbol_ptr. rdar://problem/24572729 llvm-svn: 260271
* Aligned __stub_helper section to 4-bytes.Pete Cooper2016-02-096-1/+10
| | | | | | | | | | | | ld64 aligns most of the stub's to 2 byte alignment, expect for the stub helper common atoms which are 4 byte aligned. This adds a new field to StubInfo which tracks this alignment and ensures that this is the alignment we get in the final image. rdar://problem/24570220 llvm-svn: 260248
* Add cmdline options for LC_DATA_IN_CODE load command.Pete Cooper2016-02-093-7/+13
| | | | | | | | | | | | Also added the defaults for whether to generate this load command, which the cmdline options are able to override. There was also a difference to ld64 which is fixed here in that ld64 will generate an empty data in code command if requested. rdar://problem/24472630 llvm-svn: 260191
* Generate LC_FUNCTION_STARTS load command.Pete Cooper2016-02-094-43/+144
| | | | | | | | | | | | | | This load command generates data in the LINKEDIT section which is a list of ULEB128 delta's to all of the functions in the __text section. It is then 0 terminated and pointer aligned to pad. ld64 exposes the -function-starts and no-function-starts cmdline options to override behaviour from the defaults based on file types. rdar://problem/24472630 llvm-svn: 260188
* We should never dead strip mach header symbols.Pete Cooper2016-02-091-4/+4
| | | | | | | | This was a bug in our handling of these symbols compared to ld64. Turns out that ld64 always marks these symbols as being not dead stripped. llvm-svn: 260185
* Reorder enum entry as its used for atom sorting.Pete Cooper2016-02-091-0/+1
| | | | | | | | | | The atom content type enum is used as a tie breaker to sort atoms. In that case, we want MachHeader to be before typeCode as it really will be before the code in the final executable. Test case to follow in the next commit or two. llvm-svn: 260184
* Move includes inside guards. NFC.Pete Cooper2016-02-083-9/+8
| | | | | | | These includes were before the #ifndef/#define guards. Moving them to where they should be. llvm-svn: 260153
OpenPOWER on IntegriCloud