summaryrefslogtreecommitdiffstats
path: root/llvm/lib/Target/ARM/MCTargetDesc/ARMMachObjectWriter.cpp
Commit message (Collapse)AuthorAgeFilesLines
* Move Object format code to lib/BinaryFormat.Zachary Turner2017-06-071-1/+1
| | | | | | | | | | | | 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
* Sort the remaining #include lines in include/... and lib/....Chandler Carruth2017-06-061-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | I did this a long time ago with a janky python script, but now clang-format has built-in support for this. I fed clang-format every line with a #include and let it re-sort things according to the precise LLVM rules for include ordering baked into clang-format these days. I've reverted a number of files where the results of sorting includes isn't healthy. Either places where we have legacy code relying on particular include ordering (where possible, I'll fix these separately) or where we have particular formatting around #include lines that I didn't want to disturb in this patch. This patch is *entirely* mechanical. If you get merge conflicts or anything, just ignore the changes in this patch and run clang-format over your #include lines in the files. Sorry for any noise here, but it is important to keep these things stable. I was seeing an increasing number of patches with irrelevant re-ordering of #include lines because clang-format was used. This patch at least isolates that churn, makes it easy to skip when resolving conflicts, and gets us to a clean baseline (again). llvm-svn: 304787
* Replace "fallthrough" comments with LLVM_FALLTHROUGHJustin Bogner2016-08-171-1/+1
| | | | | | | This is a mechanical change of comments in switches like fallthrough, fall-through, or fall-thru to use the LLVM_FALLTHROUGH macro instead. llvm-svn: 278902
* ARM: fix handling of movw/movt relocations with addend.Tim Northover2016-02-231-3/+6
| | | | | | | | We were emitting only one half of a the paired relocations needed for these instructions because we decided that an offset needed a scattered relocation. In fact, movw/movt relocations can be paired without being scattered. llvm-svn: 261679
* [Assembler] Make fatal assembler errors non-fatalOliver Stannard2015-11-171-11/+21
| | | | | | | | | | | | | | Currently, if the assembler encounters an error after parsing (such as an out-of-range fixup), it reports this as a fatal error, and so stops after the first error. However, for most of these there is an obvious way to recover after emitting the error, such as emitting the fixup with a value of zero. This means that we can report on all of the errors in a file, not just the first one. MCContext::reportError records the fact that an error was encountered, so we won't actually emit an object file with the incorrect contents. Differential Revision: http://reviews.llvm.org/D14717 llvm-svn: 253328
* Revert r240137 (Fixed/added namespace ending comments using clang-tidy. NFC)Alexander Kornienko2015-06-231-1/+1
| | | | | | Apparently, the style needs to be agreed upon first. llvm-svn: 240390
* Fixed/added namespace ending comments using clang-tidy. NFCAlexander Kornienko2015-06-191-1/+1
| | | | | | | | | | | | | The patch is generated using this command: tools/clang/tools/extra/clang-tidy/tool/run-clang-tidy.py -fix \ -checks=-*,llvm-namespace-comment -header-filter='llvm/.*|clang/.*' \ llvm/lib/ Thanks to Eugene Kosov for the original patch! llvm-svn: 240137
* Remove includes of MCMachOSymbolFlags.h after it was deletedPete Cooper2015-06-081-1/+0
| | | | llvm-svn: 239318
* MC: Clean up naming in MCObjectWriter. NFC.Jim Grosbach2015-06-041-2/+2
| | | | | | | | | | | | | | | | | | | | s/WriteObject/writeObject/ s/RecordRelocation/recordRelocation/ s/IsSymbolRefDifferenceFullyResolved/isSymbolRefDifferenceFullyResolved/ s/Write8/write8/ s/WriteLE16/writeLE16/ s/WriteLE32/writeLE32/ s/WriteLE64/writeLE64/ s/WriteBE16/writeBE16/ s/WriteBE32/writeBE32/ s/WriteBE64/writeBE64/ s/Write16/write16/ s/Write32/write32/ s/Write64/write64/ s/WriteZeroes/writeZeroes/ s/WriteBytes/writeBytes/ llvm-svn: 239108
* MC: Remove obsolete MachO UseAggressiveSymbolFolding.Jim Grosbach2015-06-041-4/+2
| | | | | | | | | | Fix the FIXME and remove this old as(1) compat option. It was useful for bringup of the integrated assembler to diff object files, but now it's just causing more relocations than strictly necessary to be generated. rdar://21201804 llvm-svn: 239084
* MC: Clean up MCExpr naming. NFC.Jim Grosbach2015-05-301-1/+1
| | | | llvm-svn: 238634
* Remove getData.Rafael Espindola2015-05-291-14/+10
| | | | | | This completes the mechanical part of merging MCSymbol and MCSymbolData. llvm-svn: 238617
* Remove the MCSymbolData typedef.Rafael Espindola2015-05-291-4/+4
| | | | | | The getData member function is next. llvm-svn: 238611
* Remove a trivial forwarding function. NFC.Rafael Espindola2015-05-281-4/+4
| | | | llvm-svn: 238506
* Stop using MCSectionData in MCMachObjectWriter.h.Rafael Espindola2015-05-261-10/+6
| | | | llvm-svn: 238165
* Stop using MCSectionData in MCExpr.h.Rafael Espindola2015-05-261-15/+10
| | | | llvm-svn: 238163
* Return a MCSection from MCFragment::getParent().Rafael Espindola2015-05-261-13/+21
| | | | | | Another step in merging MCSectionData and MCSection. llvm-svn: 238162
* Stop forwarding getOrdinal and setOrdinal.Rafael Espindola2015-05-251-2/+4
| | | | llvm-svn: 238139
* MC: Use MCSymbol in MachObjectWriter, NFCDuncan P. N. Exon Smith2015-05-201-19/+16
| | | | | | | Replace uses of `MCSymbolData` with `MCSymbol` where both are needed, so we can remove the backpointer. llvm-svn: 237799
* MC: Take MCSymbol in MachObjectWriter::getSymbolAddress(), NFCDuncan P. N. Exon Smith2015-05-201-4/+4
| | | | | | | Pass through an `MCSymbol` instead of an `MCSymbolData` so we can get rid of the back pointer. llvm-svn: 237750
* MC: Use MCSymbol in MCAsmLayout::getSymbolOffset(), NFCDuncan P. N. Exon Smith2015-05-191-1/+1
| | | | | | | Continue to canonicalize on MCSymbol instead of MCSymbolData when both are needed. llvm-svn: 237749
* MC: Clean up method names in MCContext.Jim Grosbach2015-05-181-5/+5
| | | | | | | The naming was a mish-mash of old and new style. Update to be consistent with the new. NFC. llvm-svn: 237594
* MC: Use MCSymbol in RelAndSymbol, NFCDuncan P. N. Exon Smith2015-05-161-2/+2
| | | | | | Switch from `MCSymbolData` to `MCSymbol`. llvm-svn: 237502
* Use raw_pwrite_stream in the object writer/streamer.Rafael Espindola2015-04-141-2/+2
| | | | | | The ELF object writer will take advantage of that in the next commit. llvm-svn: 234950
* clang-format bits of code to make a followup patch easy to read.Rafael Espindola2015-04-091-2/+1
| | | | llvm-svn: 234519
* ARM: do not relax Thumb1 -> Thumb2 if only Thumb1 is available.Tim Northover2015-04-061-6/+1
| | | | | | | | | | | | | | | After recognising that a certain narrow instruction might need a relocation to be represented, we used to unconditionally relax it to a Thumb2 instruction to permit this. Unfortunately, some CPUs (e.g. v6m) don't even have most Thumb2 instructions, so we end up emitting a completely invalid instruction. Theoretically, ELF does have relocations for these situations; but they are fairly unusable with such short ranges and the ABI document even says they're documented "for completeness". So an error is probably better there too. rdar://20391953 llvm-svn: 234195
* Add r224985 back with fixes.Rafael Espindola2015-01-191-21/+16
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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-16/+21
| | | | | | This reverts commit r225644 while I debug a regression. llvm-svn: 226022
* Add r224985 back with two fixes.Rafael Espindola2015-01-121-21/+16
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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-16/+21
| | | | | | I've filed http://llvm.org/PR22100 to track this issue. llvm-svn: 225228
* Add r224985 back with a fix.Rafael Espindola2014-12-311-21/+16
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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-16/+21
| | | | | | | | This reverts commit r224985. I am investigating why it made an Apple bot unhappy. llvm-svn: 225044
* Remove doesSectionRequireSymbols.Rafael Espindola2014-12-301-21/+16
| | | | | | | | | | | | | | | | | | | | | | | | | | | 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
* MC: Bit pack MCSymbolData.Benjamin Kramer2014-10-111-1/+1
| | | | | | | | | 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
* ARM: when falling back to scattered relocs, keep the type.Tim Northover2014-07-041-3/+7
| | | | | | | | | | The linker relies on relocation type info (e.g. is it a branch?) to perform the correct actions, so we should keep that even when we end up using a scattered relocation for whatever reason. rdar://problem/17553104 llvm-svn: 212333
* Centralize the handling of the thumb bit.Rafael Espindola2014-04-291-2/+2
| | | | | | | | | | | | | This patch centralizes the handling of the thumb bit around MCStreamer::isThumbFunc and makes isThumbFunc handle aliases. This fixes a corner case, but the main advantage is having just one way to check if a MCSymbol is thumb or not. This should still be refactored to be ARM only, but at least now it is just one predicate that has to be refactored instead of 3 (isThumbFunc, ELF_Other_ThumbFunc, and SF_ThumbFunc). llvm-svn: 207522
* [C++] Use 'nullptr'. Target edition.Craig Topper2014-04-251-1/+1
| | | | llvm-svn: 207197
* Spread some const around for non-mutating uses of MCSymbolData.David Blaikie2014-04-241-5/+5
| | | | | | | | 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
* Completely rewrite ELFObjectWriter::RecordRelocation.Rafael Espindola2014-03-291-11/+0
| | | | | | | | | | | | | | | | | | | I started trying to fix a small issue, but this code has seen a small fix too many. The old code was fairly convoluted. Some of the issues it had: * It failed to check if a symbol difference was in the some section when converting a relocation to pcrel. * It failed to check if the relocation was already pcrel. * The pcrel value computation was wrong in some cases (relocation-pc.s) * It was missing quiet a few cases where it should not convert symbol relocations to section relocations, leaving the backends to patch it up. * It would not propagate the fact that it had changed a relocation to pcrel, requiring a quiet nasty work around in ARM. * It was missing comments. llvm-svn: 205076
* [C++11] Add 'override' keyword to virtual methods that override their base ↵Craig Topper2014-03-101-1/+1
| | | | | | class. llvm-svn: 203439
* Fixed a bug in getARMFixupKindMachOInfo() where three ARM fixup kindsKevin Enderby2013-12-131-1/+5
| | | | | | | | | | | were falling into the cases for 24-bit branch kinds which are not 24-bit branches. The routine is to return false for fixups are expected to always be resolvable at assembly time. Which these three fixups are as they have limited displacement and are for local references within a function. rdar://15586725 llvm-svn: 197282
* Move everything depending on Object/MachOFormat.h over to Support/MachO.h.Charles Davis2013-09-011-65/+64
| | | | llvm-svn: 189728
* Revert "Fix the build broken by r189315." and "Move everything depending on ↵Charles Davis2013-08-271-63/+65
| | | | | | | | | Object/MachOFormat.h over to Support/MachO.h." This reverts commits r189319 and r189315. r189315 broke some tests on what I believe are big-endian platforms. llvm-svn: 189321
* Move everything depending on Object/MachOFormat.h over to Support/MachO.h.Charles Davis2013-08-271-65/+63
| | | | llvm-svn: 189315
* Use the new script to sort the includes of every file under lib.Chandler Carruth2012-12-031-2/+3
| | | | | | | | | | | | | | | | | Sooooo many of these had incorrect or strange main module includes. I have manually inspected all of these, and fixed the main module include to be the nearest plausible thing I could find. If you own or care about any of these source files, I encourage you to take some time and check that these edits were sensible. I can't have broken anything (I strictly added headers, and reordered them, never removed), but they may not be the headers you'd really like to identify as containing the API being implemented. Many forward declarations and missing includes were added to a header files to allow them to parse cleanly when included first. The main module rule does in fact have its merits. =] llvm-svn: 169131
* ARM: Darwin BL/BLX relocations to out-of-range symbols.Jim Grosbach2012-09-251-1/+48
| | | | | | | | | | | When a BL/BLX references a symbol in the same translation unit that is out of range, use an external relocation. The linker will use this to generate a branch island rather than a direct reference, allowing the relocation to resolve correctly. rdar://12359919 llvm-svn: 164615
* Remove redundant semicolons which are null statements.Dmitri Gribenko2012-09-101-1/+1
| | | | llvm-svn: 163547
* Fix a bug in ARMMachObjectWriter::RecordRelocation() in ARMMachObjectWriter.cppKevin Enderby2012-07-301-2/+9
| | | | | | | | | where the other_half of the movt and movw relocation entries needs to get set and only with the 16 bits of the other half. rdar://10038370 llvm-svn: 160978
* Fix a typo (the the => the)Sylvestre Ledru2012-07-231-1/+1
| | | | llvm-svn: 160621
* Ensure conditional BL instructions for ARM are given the fixup ↵James Molloy2012-03-301-1/+2
| | | | | | | | fixup_arm_condbranch. Patch by Tim Northover! llvm-svn: 153737
OpenPOWER on IntegriCloud