summaryrefslogtreecommitdiffstats
path: root/llvm/lib/MC/WinCOFFObjectWriter.cpp
Commit message (Collapse)AuthorAgeFilesLines
...
* MC: Change MCAssembler::Symbols to store MCSymbol, NFCDuncan P. N. Exon Smith2015-05-161-3/+3
| | | | | | | | Instead of storing a list of the `MCSymbolData` in use, store the `MCSymbol`s. Churning in the direction of removing the back pointer from `MCSymbolData`. llvm-svn: 237496
* Don't omit the constant when computing a cross-section relative relocation.Andy Ayers2015-05-141-1/+1
| | | | | | Differential Revision: http://reviews.llvm.org/D9692 llvm-svn: 237327
* Compute A-B when A or B is weak.Rafael Espindola2015-04-171-6/+4
| | | | | | | | | | | | | | | | | | | | Similar to r235222, but for the weak symbol case. In an "ideal" assembler/object format an expression would always refer to the final value and A-B would only be computed from a section in the same comdat as A and B with A and B strong. Unfortunately that is not the case with debug info on ELF, so we need an heuristic. Since we need an heuristic, we may as well use the same one as gas: * call weak_sym : produces a relocation, even if in the same section. * A - weak_sym and weak_sym -A: don't produce a relocation if we can compute it. This fixes pr23272 and changes the fix of pr22815 to match what gas does. llvm-svn: 235227
* Add a proper fix for pr23025.Rafael Espindola2015-04-171-4/+16
| | | | | | | Instead of avoiding looking past every global symbol, only do so if the symbol is in a comdat. llvm-svn: 235181
* [mc] Clean up emission of byte sequencesBenjamin Kramer2015-04-171-2/+1
| | | | | | No functional change intended. llvm-svn: 235178
* Use raw_pwrite_stream in the object writer/streamer.Rafael Espindola2015-04-141-3/+3
| | | | | | The ELF object writer will take advantage of that in the next commit. llvm-svn: 234950
* Define a function with "... llvm::func...".Rafael Espindola2015-04-091-6/+5
| | | | | | | | | | | | Using this instead of namespace llvm { func... } Has the advantage that the build fails with a compiler error if it gets out of sync with the .h file. llvm-svn: 234515
* Be consistent when deciding if a relocation is needed.Rafael Espindola2015-04-061-4/+6
| | | | | | | | | | | | | | Before when deciding if we needed a relocation in A-B, we wore only checking if A was weak. This fixes the asymmetry. The "InSet" argument should probably be renamed to "ForValue", since InSet is very MachO specific, but doing so in this patch would make it hard to read. This fixes PR22815. llvm-svn: 234165
* Remove more superfluous .str() and replace std::string concatenation with Twine.Yaron Keren2015-03-301-3/+1
| | | | | | Following r233392, http://llvm.org/viewvc/llvm-project?rev=233392&view=rev. llvm-svn: 233555
* Fix PR23025.Rafael Espindola2015-03-261-0/+8
| | | | | | | | | | | | | | | There is something in link.exe that requires a relocation to use a global symbol. Not doing so breaks the chrome build on windows. This patch sets isWeak for that to work. To compensate, we then need to look past those symbols when not creating relocations. This patch includes an ELF test that matches GNU as behaviour. I am still reducing the chrome build issue and will add a test once that is done. llvm-svn: 233318
* Unbreak buildbotsDavid Majnemer2015-02-111-1/+2
| | | | | | The next offset should be updated as well. llvm-svn: 228883
* MC, COFF: Align section contents to a four byte boundaryDavid Majnemer2015-02-111-2/+9
| | | | llvm-svn: 228879
* MC: Calculate intra-section symbol differences correctly for COFFDavid Majnemer2015-02-091-6/+11
| | | | | | This fixes PR22060. llvm-svn: 228565
* ARM: fail less catastrophically on invalid Windows inputSaleem Abdulrasool2015-01-221-2/+3
| | | | | | | | | | | | Windows supports a restricted set of relocations (compared to ARM ELF). In some cases, we may end up generating an unsupported relocation. This can occur with bad input to the assembler in particular (the frontend should never generate code that cannot be compiled). Generate an error rather than just aborting. The change in the API is driven by the desire to provide a slightly more helpful message for debugging purposes. llvm-svn: 226779
* Add r224985 back with fixes.Rafael Espindola2015-01-191-8/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The fixes are to note that AArch64 has additional restrictions on when local relocations can be used. In particular, ld64 requires that relocations to cstring/cfstrings use linker visible symbols. Original message: In an assembly expression like bar: .long L0 + 1 the intended semantics is that bar will contain a pointer one byte past L0. In sections that are merged by content (strings, 4 byte constants, etc), a single position in the section doesn't give the linker enough information. For example, it would not be able to tell a relocation must point to the end of a string, since that would look just like the start of the next. The solution used in ELF to use relocation with symbols if there is a non-zero addend. In MachO before this patch we would just keep all symbols in some sections. This would miss some cases (only cstrings on x86_64 were implemented) and was inefficient since most relocations have an addend of 0 and can be represented without the symbol. This patch implements the non-zero addend logic for MachO too. llvm-svn: 226503
* Revert "Add r224985 back with two fixes."Rafael Espindola2015-01-141-4/+8
| | | | | | This reverts commit r225644 while I debug a regression. llvm-svn: 226022
* [cleanup] Re-sort all the #include lines in LLVM usingChandler Carruth2015-01-141-1/+1
| | | | | | | | | | | utils/sort_includes.py. I clearly haven't done this in a while, so more changed than usual. This even uncovered a missing include from the InstrProf library that I've added. No functionality changed here, just mechanical cleanup of the include order. llvm-svn: 225974
* Add r224985 back with two fixes.Rafael Espindola2015-01-121-8/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | One is that AArch64 has additional restrictions on when local relocations can be used. We have to take those into consideration when deciding to put a L symbol in the symbol table or not. The other is that ld64 requires the relocations to cstring to use linker visible symbols on AArch64. Thanks to Michael Zolotukhin for testing this! Remove doesSectionRequireSymbols. In an assembly expression like bar: .long L0 + 1 the intended semantics is that bar will contain a pointer one byte past L0. In sections that are merged by content (strings, 4 byte constants, etc), a single position in the section doesn't give the linker enough information. For example, it would not be able to tell a relocation must point to the end of a string, since that would look just like the start of the next. The solution used in ELF to use relocation with symbols if there is a non-zero addend. In MachO before this patch we would just keep all symbols in some sections. This would miss some cases (only cstrings on x86_64 were implemented) and was inefficient since most relocations have an addend of 0 and can be represented without the symbol. This patch implements the non-zero addend logic for MachO too. llvm-svn: 225644
* Revert r225048: It broke ObjC on AArch64.Lang Hames2015-01-061-4/+8
| | | | | | I've filed http://llvm.org/PR22100 to track this issue. llvm-svn: 225228
* Add r224985 back with a fix.Rafael Espindola2014-12-311-8/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The issues was that AArch64 has additional restrictions on when local relocations can be used. We have to take those into consideration when deciding to put a L symbol in the symbol table or not. Original message: Remove doesSectionRequireSymbols. In an assembly expression like bar: .long L0 + 1 the intended semantics is that bar will contain a pointer one byte past L0. In sections that are merged by content (strings, 4 byte constants, etc), a single position in the section doesn't give the linker enough information. For example, it would not be able to tell a relocation must point to the end of a string, since that would look just like the start of the next. The solution used in ELF to use relocation with symbols if there is a non-zero addend. In MachO before this patch we would just keep all symbols in some sections. This would miss some cases (only cstrings on x86_64 were implemented) and was inefficient since most relocations have an addend of 0 and can be represented without the symbol. This patch implements the non-zero addend logic for MachO too. llvm-svn: 225048
* Revert "Remove doesSectionRequireSymbols."Rafael Espindola2014-12-311-4/+8
| | | | | | | | This reverts commit r224985. I am investigating why it made an Apple bot unhappy. llvm-svn: 225044
* Remove doesSectionRequireSymbols.Rafael Espindola2014-12-301-8/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | In an assembly expression like bar: .long L0 + 1 the intended semantics is that bar will contain a pointer one byte past L0. In sections that are merged by content (strings, 4 byte constants, etc), a single position in the section doesn't give the linker enough information. For example, it would not be able to tell a relocation must point to the end of a string, since that would look just like the start of the next. The solution used in ELF to use relocation with symbols if there is a non-zero addend. In MachO before this patch we would just keep all symbols in some sections. This would miss some cases (only cstrings on x86_64 were implemented) and was inefficient since most relocations have an addend of 0 and can be represented without the symbol. This patch implements the non-zero addend logic for MachO too. llvm-svn: 224985
* clang-formatted ranged loops and assignment, NFC.Yaron Keren2014-12-041-12/+12
| | | | llvm-svn: 223344
* MC, COFF: Use relocations for function references inside the sectionDavid Majnemer2014-11-111-0/+18
| | | | | | | | | | | | | | | | | | Referencing one symbol from another in the same section does not generally require a relocation. However, the MS linker has a feature called /INCREMENTAL which enables incremental links. It achieves this by creating thunks to the actual function and redirecting all relocations to point to the thunk. This breaks down with the old scheme if you have a function which references, say, itself. On x86_64, we would use %rip relative addressing to reference the start of the function from out current position. This would lead to miscompiles because other references might reference the thunk instead, breaking function pointer equality. This fixes PR21520. llvm-svn: 221678
* speling.Nico Weber2014-11-111-1/+1
| | | | llvm-svn: 221652
* MC: Bit pack MCSymbolData.Benjamin Kramer2014-10-111-4/+4
| | | | | | | | | On x86_64 this brings it from 80 bytes to 64 bytes. Also make any member variables private and clean up uses to go through the existing accessors. NFC. llvm-svn: 219573
* WinCOFFObjectWriter: optimize the string table for common sufficesHans Wennborg2014-09-291-85/+33
| | | | | | | | This is a follow-up from r207670 which did the same for ELF. Differential Revision: http://reviews.llvm.org/D5530 llvm-svn: 218636
* WinCOFFObjectWriter.cpp: make write_uint32_le more efficientHans Wennborg2014-09-281-6/+4
| | | | llvm-svn: 218574
* This add a reset method for WinCOFFObjectWriter, like other MC* classes.Yaron Keren2014-09-161-0/+16
| | | | llvm-svn: 217907
* Fix the build for MSVC, it doesn't support extended sizeofDavid Majnemer2014-09-151-4/+4
| | | | llvm-svn: 217820
* MC: Add support for BigObjDavid Majnemer2014-09-151-59/+91
| | | | | | | | | | | | | | | | | | | | | | | | Teach WinCOFFObjectWriter how to write -mbig-obj style object files; these object files allow for more sections inside an object file. Our support for BigObj is notably different from binutils and cl: we implicitly upgrade object files to BigObj instead of asking the user to compile the same file *again* but with another flag. This matches up with how LLVM treats ELF variants. This was tested by forcing LLVM to always emit BigObj files and running the entire test suite. A specific test has also been added. I've lowered the maximum number of sections in a normal COFF file, VS "14" CTP 3 supports no more than 65279 sections. This is important otherwise we might not switch to BigObj quickly enough, leaving us with a COFF file that we couldn't link. yaml2obj support is all that remains to implement. Differential Revision: http://reviews.llvm.org/D5349 llvm-svn: 217812
* Object: Add support for bigobjDavid Majnemer2014-09-101-1/+1
| | | | | | | | | | | | | | | | | | | | | | This adds support for reading the "bigobj" variant of COFF produced by cl's /bigobj and mingw's -mbig-obj. The most significant difference that bigobj brings is more than 2**16 sections to COFF. bigobj brings a few interesting differences with it: - It doesn't have a Characteristics field in the file header. - It doesn't have a SizeOfOptionalHeader field in the file header (it's only used in executable files). - Auxiliary symbol records have the same width as a symbol table entry. Since symbol table entries are bigger, so are auxiliary symbol records. Write support will come soon. Differential Revision: http://reviews.llvm.org/D5259 llvm-svn: 217496
* Silence a -Wsign-compare warning. NFC.Aaron Ballman2014-08-281-1/+1
| | | | llvm-svn: 216666
* MC: Don't crash when the COFF section limit is reachedDavid Majnemer2014-08-281-6/+11
| | | | | | | I've decided not to commit a test, it takes 2.5 seconds to run on my an incredibly strong machine. llvm-svn: 216647
* MC: Let non-temporary COFF aliases be in symtabDavid Majnemer2014-07-131-8/+19
| | | | | | | | | | | | | | MC was aping a binutils bug where aliases would default their linkage to private instead of internal. I've sent a patch to the binutils maintainers and they've recently applied it to the GNU assembler sources. This fixes PR20152. Differential Revision: http://reviews.llvm.org/D4395 llvm-svn: 212899
* MC: Correct comment in ExportSymbolDavid Majnemer2014-07-041-1/+1
| | | | | | | No functionality changed, just make it so that the code _could_ be uncommented. llvm-svn: 212363
* MC: prevent early DCE of empty sectionsSaleem Abdulrasool2014-06-061-7/+3
| | | | | | | | | | | | | | | | Prevent the early elimination of sections in the object writer. There may be references to the section itself by other symbols, which may potentially not be possible to resolve. ML (Visual Studio's Macro Assembler) also seems to retain empty sections. The elimination of symbols and sections which are unused should really occur at the link phase. This will not cause any change in the resulting binary, simply in the generated object files. The adjustments to the other unit tests account for the fluctuating section index caused by the appearance of sections which were previously discarded. llvm-svn: 210373
* Fix a few issues with comdat handling on COFF.Rafael Espindola2014-06-061-6/+24
| | | | | | | | | | | | | | | | | | | | | * Section association cannot use just the section name as many sections can have the same name. With this patch, the comdat symbol in an assoc section is interpreted to mean a symbol in the associated section and the mapping is discovered from it. * Comdat symbols were not being set correctly. Instead we were getting whatever was output first for that section. A consequence is that associative sections now must use .section to set the association. Using .linkonce would not work since it is not possible to change a sections comdat symbol (it is used to decide if we should create a new section or reuse an existing one). This includes r210298, which was reverted because it was asserting on an associated section having the same comdat as the associated section. llvm-svn: 210367
* Revert r210298 'Correctly set the comdat symbol on COFF' as it asserts on ↵Timur Iskhodzhanov2014-06-061-13/+2
| | | | | | Windows llvm-svn: 210317
* Correctly set the comdat symbol on COFF.Rafael Espindola2014-06-051-2/+13
| | | | | | | | | | | | | | | | | | | | | We extended the .section syntax to allow multiple sections with the same name but different comdats, but currently we don't make sure that the output section has that comdat symbol. That happens to work with the code llc produces currently because it looks like .section secName, "dr", one_only, "COMDATSym" .globl COMDATSym COMDATSym: .... but that is not very friendly to anyone coding in assembly or even to llc once we get comdat support in the IR. This patch changes the coff object writer to make sure the comdat symbol is output just after the section symbol, as required by the coff spec. llvm-svn: 210298
* MC: introduce ability to restrict recorded relocationsSaleem Abdulrasool2014-05-211-1/+2
| | | | | | | | | Add support to allow a target specific COFF object writer to restrict the recorded resolutions in the emitted object files. This is motivated by the need in Windows on ARM, where an intermediate relocation needs to be prevented from being emitted in the object file. llvm-svn: 209336
* Fix typosAlp Toker2014-05-151-1/+1
| | | | llvm-svn: 208839
* MC: place .file records into the correct sectionSaleem Abdulrasool2014-05-021-0/+1
| | | | | | | | | .file records are supposed to have a section identifier of 65534 (IMAGE_SCN_DEBUG) rather than 0. This is spelt out clearly within the PE/COFF specification. Fix this minor oversight with the implementation for support for .file records. llvm-svn: 207851
* Don't propagate StorageClass and ComplexType to aliases.Rafael Espindola2014-05-011-2/+1
| | | | | | | | | This matches gas' behaviour on COFF. I think that this yak is now sufficiently shaved for aliases with offset to work. llvm-svn: 207786
* Compute the correct section for zed = foo + 1 in COFF.Rafael Espindola2014-05-011-10/+9
| | | | | | | | | This fixes pr19147. There are a few more related issues to fix, but the testcase in the bug now passes. llvm-svn: 207763
* Start fixing pr19147.Rafael Espindola2014-05-011-10/+13
| | | | | | | This makes the coff writer compute the correct symbol value for the test in pr19147. The section is still incorrect, that will be fixed in a followup patch. llvm-svn: 207728
* MC: range-loopifySaleem Abdulrasool2014-04-281-62/+49
| | | | | | Use C++11 range-based loops rather than explicit constructors. NFC. llvm-svn: 207393
* Add WoA object file emission supportSaleem Abdulrasool2014-04-271-0/+38
| | | | | | | | | | | | | | | | | | | | | | Introduce support for WoA PE/COFF object file emission from LLVM. Add the new target specific PE/COFF Streamer (ARMWinCOFFStreamer) that handles the ARM specific behaviour of PE/COFF object emission. ARM exception information is not yet emitted and is a TODO item. The ARM specific object writer (ARMWinCOFFObjectWriter) handles the ARM specific relocation handling in conjunction with the WinCOFFObjectWriter in the MC layer. The MC layer needs to be updated to deal with the relocation adjustments. Branch relocations are adjusted by 4 bytes (unlikely their ELF counterparts). Minor tweaks to switch multiple conditional checks into equivalent switch statements. The ObjectFileInfo is updated to relax the object file setup for Windows COFF. Move the architecture checks into an assertion. Windows COFF is currently only supported on x86, x86_64, and ARM (thumb). Rather than defaulting to ELF, we will refuse to generate an object file. This is better though as you do not get an (arbitrary) object file which is different from the request. llvm-svn: 207345
* Spread some const around for non-mutating uses of MCSymbolData.David Blaikie2014-04-241-2/+2
| | | | | | | | I discovered this const-hole while attempting to coalesnce the Symbol and SymbolMap data structures. There's some pending issues with that, but I figured this change was easy to flush early. llvm-svn: 207124
* [C++] Use 'nullptr'.Craig Topper2014-04-241-1/+1
| | | | llvm-svn: 207083
OpenPOWER on IntegriCloud