aboutsummaryrefslogtreecommitdiff
path: root/llvm/lib/MC/WinCOFFObjectWriter.cpp
AgeCommit message (Collapse)AuthorFilesLines
2017-06-23COFF: Produce an error on invalid pcrel relocs.Rafael Espindola1-2/+2
X86_64 COFF only has support for 32 bit pcrel relocations. Produce an error on all others. Note that gnu as has extended the relocation values to support this. It is not clear if we should support the gnu extension. llvm-svn: 306082
2017-06-23COFF: handle "undef - ." expressions.Rafael Espindola1-11/+0
This is another thing that the ELF implementation can do but is missing from COFF. llvm-svn: 306078
2017-06-22Change creation of relative relocations on COFF.Rafael Espindola1-1/+1
For whatever reason, when processing .globl foo foo: .data bar: .long foo-bar llvm-mc creates a relocation with the section: 0x0 IMAGE_REL_I386_REL32 .text This is different than when the relocation is relative from the beginning. For example, a file with call foo produces 0x0 IMAGE_REL_I386_REL32 foo I would like to refactor the logic for converting "foo - ." into a relative relocation so that it is shared with ELF. This is the first step and just changes the coff implementation to match what ELF (and COFF in the case of calls) does. llvm-svn: 306063
2017-06-22Simplify WinCOFFObjectWriter::recordRelocation.Rafael Espindola1-14/+5
It looks like that when this code was written recordRelocation could be called with A-B where A and B are in the same section. The expression evaluation logic these days makes sure those are folded, so some of this code was dead. llvm-svn: 306053
2017-06-07Move Object format code to lib/BinaryFormat.Zachary Turner1-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
2017-06-06Sort the remaining #include lines in include/... and lib/....Chandler Carruth1-3/+3
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
2017-04-26[MC] Fix some Clang-tidy modernize-use-using warnings; other minor fixes (NFC).Eugene Zelenko1-7/+8
llvm-svn: 301485
2017-04-08MC: Remove unused virtual function MCObjectWriter::isWeak. NFC.Peter Collingbourne1-19/+0
llvm-svn: 299817
2017-02-17MC/COFF: Do not emit forward associative section referenceds.Rui Ueyama1-26/+53
MSVC link.exe cannot handle associative sections that refer later sections in the section header. Technically, such COFF object doesn't violate the Microsoft COFF spec, as the spec doesn't say anything about that, but still we should avoid doing that to make it compatible with MS tools. This patch assigns smaller section numbers to non-associative sections and larger numbers to associative sections. This should resolve the compatibility issue. Differential Revision: https://reviews.llvm.org/D30080 llvm-svn: 295464
2017-02-16Split WinCOFFObjectWriter::writeSection.Rui Ueyama1-28/+39
llvm-svn: 295276
2017-02-16Split WinCOFFObjectWriter::writeObject function.Rui Ueyama1-160/+183
llvm-svn: 295273
2017-02-16Remove useless local variable.Rui Ueyama1-9/+4
llvm-svn: 295268
2017-02-16Rename variables to match the LLVM style.Rui Ueyama1-94/+97
llvm-svn: 295265
2017-02-15Revert r295138: Instead of a series of string operations, use snprintf().Rui Ueyama1-2/+4
This broke buildbots. llvm-svn: 295142
2017-02-15Instead of a series of string operations, use snprintf().Rui Ueyama1-4/+2
llvm-svn: 295138
2017-02-15Return early. NFC.Rui Ueyama1-16/+17
llvm-svn: 295137
2017-02-15Use LLVM-style naming scheme.Rui Ueyama1-22/+22
llvm-svn: 295136
2017-02-15Use LLVM-style naming scheme.Rui Ueyama1-18/+18
llvm-svn: 295132
2017-02-15Remove useless local variable.Rui Ueyama1-3/+1
llvm-svn: 295131
2017-02-15Split WinCOFFObjectWriter::defineSection. NFC.Rui Ueyama1-47/+38
llvm-svn: 295128
2017-02-14Simplify WinCOFFObjectWriter by removing a template member function.Rui Ueyama1-15/+5
llvm-svn: 295126
2017-02-14Do not lookup a DenseMap twice using the same key.Rui Ueyama1-7/+4
llvm-svn: 295124
2017-02-14Use endian::write32le instead of endian::write.Rui Ueyama1-7/+3
llvm-svn: 295120
2017-02-14Use zero-initialization instead of memset.Rui Ueyama1-18/+5
llvm-svn: 295119
2017-02-07[MC] Fix some Clang-tidy modernize and Include What You Use warnings; other ↵Eugene Zelenko1-25/+34
minor fixes (NFC). llvm-svn: 294369
2016-11-20Fix comment typos. NFC.Simon Pilgrim1-1/+1
Identified by Pedro Giffuni in PR27636. llvm-svn: 287490
2016-10-24Remove unused #includes of TimeValue.h. NFC.Pavel Labath1-1/+0
llvm-svn: 284975
2016-10-04Misc improvements to StringTableBuilder.Rafael Espindola1-1/+1
This patch adds write methods to StringTableBuilder so that it is easier to change the underlying implementation. Using the write methods, avoid creating a temporary buffer when using mmaped output. It also uses a more compact key in the DenseMap. Overall this produces a slightly faster lld: firefox master 6.853419709 patch 6.841968912 1.00167361138x faster chromium master 4.297280174 patch 4.298712163 1.00033323147x slower chromium fast master 1.802335952 patch 1.806872459 1.00251701521x slower the gold plugin master 0.3247149 patch 0.321971644 1.00852017888x faster clang master 0.551279945 patch 0.543733194 1.01387951128x faster llvm-as master 0.032743458 patch 0.032143478 1.01866568391x faster the gold plugin fsds master 0.350814247 patch 0.348571741 1.00643341309x faster clang fsds master 0.6281672 patch 0.621130222 1.01132931187x faster llvm-as fsds master 0.030168899 patch 0.029797155 1.01247582194x faster scylla master 3.104222518 patch 3.059590248 1.01458766252x faster llvm-svn: 283266
2016-06-26Apply clang-tidy's modernize-loop-convert to lib/MC.Benjamin Kramer1-25/+24
Only minor manual fixes. No functionality change intended. llvm-svn: 273814
2016-06-21Delete some dead code.Rafael Espindola1-3/+0
Found by gcc 6. llvm-svn: 273303
2016-05-26coff: fix weak alias to local.Rafael Espindola1-32/+40
We were creating a weak external that tried to reference a static symbol. That would always fail to link with link.exe. We now create an external symbol in the same position as the local and refer to that. This works with link.exe and matches what gas does. llvm-svn: 270906
2016-05-26coff: fix the section of weak symbols.Rafael Espindola1-13/+16
llvm-svn: 270889
2016-05-26coff: fix the value of weak definitions.Rafael Espindola1-1/+1
It looks like this doesn't get a lot of use. llvm-svn: 270883
2016-02-05[MC] Add support for encoding CodeView variable definition rangesDavid Majnemer1-0/+4
CodeView, like most other debug formats, represents the live range of a variable so that debuggers might print them out. They use a variety of records to represent how a particular variable might be available (in a register, in a frame pointer, etc.) along with a set of ranges where this debug information is relevant. However, the format only allows us to use ranges which are limited to a maximum of 0xF000 in size. This means that we need to split our debug information into chunks of 0xF000. Because the layout of code is not known until *very* late, we must use a new fragment to record the information we need until we can know *exactly* what the range is. llvm-svn: 259868
2016-01-24[COFF] Simplify SetSectionNameDavid Majnemer1-12/+10
Consolidate the code which handles string table offsets less than 999999 with the code for offsets less than 9999999. While we are here, simplify the code by not using sprintf to generate the string. llvm-svn: 258664
2016-01-14Update to use new name alignTo().Rui Ueyama1-1/+1
llvm-svn: 257804
2016-01-06Make WinCOFFObjectWriter.cpp's timestamp writing not use ENABLE_TIMESTAMPSNico Weber1-7/+1
LLVM_ENABLE_TIMESTAMPS controls if timestamps are embedded into llvm's binaries. Turning it off is useful for deterministic builds. r246905 made it so that the define suddenly also controls if the binaries that the llvm binaries _create_ embed timestamps or not – but this shouldn't be a configure-time option. r256203/r256204 added a driver option to toggle this on and off, so this patch now passes this driver option in LLVM_ENABLE_TIMESTAMPS builds so that if LLVM_ENABLE_TIMESTAMPS is set, the build of LLVM is deterministic – but the built clang can still write timestamps into other executables when requested. This also allows removing some of the test machinery added in r292012 to work around this problem. See PR24740 for background. http://reviews.llvm.org/D15783 llvm-svn: 256958
2015-12-21[MC, COFF] Support link /incremental conditionallyDavid Majnemer1-5/+12
Today, we always take into account the possibility that object files produced by MC may be consumed by an incremental linker. This results in us initialing fields which vary with time (TimeDateStamp) which harms hermetic builds (e.g. verifying a self-host went well) and produces sub-optimal code because we cannot assume anything about the relative position of functions within a section (call sites can get redirected through incremental linker thunks). Let's provide an MCTargetOption which controls this behavior so that we can disable this functionality if we know a-priori that the build will not rely on /incremental. llvm-svn: 256203
2015-12-21[MC, COFF] Unbreak support for COFF timestampsDavid Majnemer1-0/+1
Support for COFF timestamps was unintentionally broken in r246905 when it was conditionally available depending on whether or not LLVM was configured with LLVM_ENABLE_TIMESTAMPS. However, Config/config.h was never included which essentially broke the feature. Due to lax testing, the breakage was never identified until we observed strange failures during incremental links of Chromium. This issue is resolved by simply including Config/config.h in WinCOFFObjectWriter and teaching lit that the MC/COFF/timestamp.s test is conditionally supported depending on LLVM_ENABLE_TIMESTAMPS. With this in place, we can strengthen the test to ensure that it will not accidentally get broken in the future. This fixes PR25891. llvm-svn: 256137
2015-11-26MC: Simplify handling of temporary symbols in COFF writer.Peter Collingbourne1-81/+23
The COFF object writer was previously adding unnecessary symbols to its temporary data structures and cleaning them up later. This made the code harder to understand and caused a bug (aliases classed as temporary symbols would cause an assertion failure). A much simpler way of handling such symbols is to ask the layout for their section-relative position when needed. Tested with a bootstrap on Windows and by building Chrome. Differential Revision: http://reviews.llvm.org/D14975 llvm-svn: 254183
2015-11-18Fix bug where WinCOFFObjectWriter would assume starting from an empty output.Manuel Klimek1-1/+1
Starting on an input stream that is not at offset 0 would trigger the assert in WinCOFFObjectWriter.cpp:1065: assert(getStream().tell() <= (*i)->Header.PointerToRawData && "Section::PointerToRawData is insane!"); llvm-svn: 253464
2015-11-17[Assembler] Make fatal assembler errors non-fatalOliver Stannard1-7/+14
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
2015-10-23Add a RAW mode to StringTableBuilder.Rafael Espindola1-2/+2
In this mode it just tries to tail merge the strings without imposing any other format constrains. It will not, for example, add a null byte between them. Also add support for keeping a tentative size and offset if we decide to not optimize after all. This will be used shortly in lld for merging SHF_STRINGS sections. llvm-svn: 251153
2015-09-16Add assembler fatal error for undefined assembler labels in COFF writerReid Kleckner1-0/+5
llvm-svn: 247814
2015-09-05WinCOFFObjectWriter.cpp: Roll back TimeDateStamp along ENABLE_TIMESTAMPS.NAKAMURA Takumi1-0/+5
We want a deterministic output. GNU AS leaves it zero. FIXME: It may be optional by its user, like llc and clang. llvm-svn: 246905
2015-09-04[MC] Replace comparison with isUInt<32>.David Majnemer1-1/+1
Casting to unsigned long can cause the time to get truncated to 32-bits, making it appear to be a valid timestamp. Just use isUInt<32> instead. llvm-svn: 246840
2015-09-04WinCOFFObjectWriter.cpp: Appease a warning in checking std::time_t. ↵NAKAMURA Takumi1-1/+1
[-Wsign-compare] llvm-svn: 246839
2015-09-01[MC] Generate a timestamp for COFF object filesDavid Majnemer1-2/+7
The MS incremental linker seems to inspect the timestamp written into the object file to determine whether or not it's contents need to be considered. Failing to set the timestamp to a date newer than the executable will result in the object file not participating in subsequent links. To ameliorate this, write the current time into the object file's TimeDateStamp field. llvm-svn: 246607
2015-09-01[MC] Add support for generating COFF CRCsDavid Majnemer1-0/+28
COFF sections are accompanied with an auxiliary symbol which includes a checksum. This checksum used to be filled with just zero but this seems to upset LINK.exe when it is processing a /INCREMENTAL link job. Instead, fill the CheckSum field with the JamCRC of the section contents. This matches MSVC's behavior. This fixes PR19666. N.B. A rather simple implementation of JamCRC is given. It implements a byte-wise calculation using the method given by Sarwate. There are implementations with higher throughput like slice-by-eight and making use of PCLMULQDQ. We can switch to one of those techniques if it turns out to be a significant use of time. llvm-svn: 246590
2015-09-01[MC] Allow MCObjectWriter's output stream to be swapped outDavid Majnemer1-5/+6
There are occasions where it is useful to consider the entirety of the contents of a section. For example, compressed debug info needs the entire section available before it can compress it and write it out. The compressed debug info scenario was previously implemented by mirroring the implementation of writeSectionData in the ELFObjectWriter. Instead, allow the output stream to be swapped on demand. This lets callers redirect the output stream to a more convenient location before it hits the object file. No functionality change is intended. Differential Revision: http://reviews.llvm.org/D12509 llvm-svn: 246554
generated by cgit v1.1 at 2025-09-30 00:37:14 +0000