summaryrefslogtreecommitdiffstats
path: root/lld/COFF
Commit message (Collapse)AuthorAgeFilesLines
* [PDB] Remove dots and normalize slashes with /PDBSOURCEPATH.Zachary Turner2019-02-061-6/+12
| | | | | | | | | | | | | | | | | | | | | | | | | | | In a previous patch, I made changes so that PDBs which were generated on non-Windows platforms contained sensical paths for the host. While this is an esoteric use case, we need it to be supported for certain cross compilation scenarios especially with LLDB, which can debug things on non-Windows platforms. However, this regressed a case where you specify /PDBSOURCEPATH and use a windows-style path. Previously, we would still remove dots and canonicalize slashes to backslashes, but since my change intentionally tried to support non-backslash paths, this was broken. This patch fixes the situation by trying to guess which path style the user is specifying when /PDBSOURCEPATH is passed. It is intentionally conservative, erring on the side of a Windows path style unless absolutely certain. All dots are removed and slashes canonicalized to whatever the deduced path style is after appending the file path to the /PDBSOURCEPATH argument. Differential Revision: https://reviews.llvm.org/D57769 llvm-svn: 353250
* [COFF] Avoid O(n^2) accesses into PartialSectionsMartin Storsjo2019-02-051-21/+21
| | | | | | | | | | | | | | | | | | | | | | | For MinGW, unique partial sections are much more common, e.g. comdat functions get sections named e.g. text$symbol. A moderate sized example of this contains over 200K Chunks which create 174K unique PartialSections. Prior to SVN r352928 (D57574), linking this took around 1,5 seconds for me, while it afterwards takes around 13 minutes. After this patch, the linking time is back to what it was before. The std::find_if in findPartialSection will do a linear scan of the whole container until a match is found. To use something like binary_search or the std::set container's own methods, we'd need to already have a PartialSection*. Reinstate a proper map instead of having a set with a custom sorting comparator. Differential Revision: https://reviews.llvm.org/D57666 llvm-svn: 353146
* [COFF] Create range extension thunks for ARM64Martin Storsjo2019-02-013-16/+70
| | | | | | | | | | | | | | On ARM64, this is normally necessary only after a module exceeds 128 MB in size (while the limit for thumb is 16 MB). For conditional branches, the range limit is only 1 MB though (the same as for thumb), and for the tbz instruction, the range is only 32 KB, which allows for a test much smaller than the full 128 MB. This fixes PR40467. Differential Revision: https://reviews.llvm.org/D57575 llvm-svn: 352929
* [COFF] Fix crashes when writing a PDB after adding thunks.Martin Storsjo2019-02-011-5/+6
| | | | | | | | | | | | When writing a PDB, the OutputSection of all chunks need to be set. The thunks are added directly to OutputSection after the normal machinery that sets it for all other chunks. This fixes part of PR40467. Differential Revision: https://reviews.llvm.org/D57574 llvm-svn: 352928
* Fix names of functions in TargetOptionsCommandFlags.h. NFC.Sam Clegg2019-02-011-3/+3
| | | | | | Differential Revision: https://reviews.llvm.org/D57555 llvm-svn: 352825
* lld-link: Allow mixing 'discard' and 'largest' comdat selectionsNico Weber2019-01-311-9/+17
| | | | | | | | | | | | | | | | | | | cl.exe and clang-cl.exe put vftables in a 'discard' comdat when building with RTTI disabled (/GR-) but in a 'largest' comdat when building with RTTI enabled. To be able to link /GR- code with /GR code, lld-link needs to accept comdats that have this type of comdat selection conflict. For example, static libraries in the Visual Studio standard library are built with /GR, and without this it's impossible to build client code with /GR- and still link to the standard library. link.exe also accepts merging 'discard' with 'largest', and it accepts merging 'largest' with any other selection type. lld-link is still a bit stricter since it only allows merging 'largest' with 'discard' for symmetry. Differential Revision: https://reviews.llvm.org/D57515 llvm-svn: 352765
* [LTO] Set CGOptLevel in LTO config.Sam Clegg2019-01-301-0/+2
| | | | | | | | | Previously we were never setting this which means it was always being set to Default (-O2/-Os). Differential Revision: https://reviews.llvm.org/D57422 llvm-svn: 352667
* lld/coff: Implement some support for the comdat selection fieldNico Weber2019-01-304-16/+135
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | LLD used to handle comdats as if the selection field was always set to IMAGE_COMDAT_SELECT_ANY. This means for obj files produced by `cl /Gy`, LLD would never report a duplicate symbol error. This change: - adds validation for the Selection field (should make no difference in practice for compiler-generated obj inputs) - rejects comdats that have different Selection fields in different obj files (likewise). This is a bit more strict but also more self-consistent thank link.exe (see comment in code) - implements handling for all the selection kinds In practice, compilers only generate comdats with IMAGE_COMDAT_SELECT_NODUPLICATES (LLD now produces duplicate symbol errors for these), IMAGE_COMDAT_SELECT_ANY (no behavior change), and IMAGE_COMDAT_SELECT_LARGEST (for RTTI data; here LLD should no longer create broken executables when linking some TUs with RTTI enabled and some with it disabled – but see below). The implementation of `IMAGE_COMDAT_SELECT_LARGEST` is incomplete: If one SELECT_LARGEST comdat replaces an earlier one, the comdat symbol is replaced correctly, but the old section stays loaded and if /opt:ref is disabled (via /opt:noref or /debug) it's still written to the output. That's not ideal, but better than the current treatment of just picking any one of those comdats. I hope to fix this better later. Fixes most of PR40094. Differential Revision: https://reviews.llvm.org/D57324 llvm-svn: 352590
* lld-link: Allow backward references between associated comdatsNico Weber2019-01-291-8/+4
| | | | | | | | | | | | | | | | | References between associated comdats are invalid per COFF spec, but the newest Windows SDK contains obj files that have these references (https://bugs.chromium.org/p/chromium/issues/detail?id=925943#c13). So add back support for them and add tests for them. The old code handled them fine. This makes lld-link match the behavior of newer link.exe versions as far as I can tell. (The behavior before this change matched the behavior of older link.exe versions.) This mostly reverts r352254. Differential Revision: https://reviews.llvm.org/D57387 llvm-svn: 352508
* lld/coff: Make assoc comdat diag a bit more detailedNico Weber2019-01-281-3/+4
| | | | | | | | | Many different sections can have the same name, so include the indices of the sections mentioned in the diagnostic too. I'm debugging something I can't repro locally, maybe this will help. llvm-svn: 352428
* [LLD][COFF] Partial sectionsAlexandre Ganea2019-01-281-50/+95
| | | | | | | | Persist (input) sections that make up an OutputSection. This is a supporting patch for the upcoming D54802. Differential Revision: https://reviews.llvm.org/D55293 llvm-svn: 352336
* [COFF] Add support for the new relocation IMAGE_REL_ARM{,64}_REL32Martin Storsjo2019-01-271-0/+2
| | | | | | Differential Revision: https://reviews.llvm.org/D57292 llvm-svn: 352325
* Follow-up to r352254: Initialize Selection field.Nico Weber2019-01-271-1/+1
| | | | | | The diagnostic there fired spuriosly due to uninitialized memory. llvm-svn: 352304
* lld-link: Store comdat selection in SectionChunk, reject more invalid ↵Nico Weber2019-01-262-5/+19
| | | | | | | | | | | | | | associated comdats I need the comdat selection for PR40094. To keep the patch for that smaller, I'm adding it here, and as a first application I'm using it to reject associative comdats referring to earlier associative comdats. Depends on D56929; together with that all associative comdats referring to other associative comdats are now rejected. Differential Revision: https://reviews.llvm.org/D56931 llvm-svn: 352254
* Fix broken export table if .rdata is merged with .text.Rui Ueyama2019-01-241-1/+15
| | | | | | | | | | | | | | | | | | Previously, we assumed that .rdata is zero-filled, so when writing an COFF import table, we didn't write anything if the data is zero. That assumption was wrong because .rdata can be merged with .text. If .rdata is merged with .text, they are initialized with 0xcc which is a trap instruction. This patch removes that assumption from code. Should be merged to 8.0 branch as this is a regression. Fixes https://bugs.llvm.org/show_bug.cgi?id=39826 Differential Revision: https://reviews.llvm.org/D57168 llvm-svn: 352082
* lld-link: Use just one code path to process associative comdats, reject some ↵Nico Weber2019-01-231-18/+20
| | | | | | | | | | | | | | | | | | | invalid associated comdats Currently, if an associative comdat appears after the comdat it's associated with it's processed immediately, else it's deferred until the end of the object file. I found this confusing to think about while working on PR40094, so this makes it so that associated comdats are always processed at the end of the object file. This seems to be perf-neutral and simpler. Now there's a natural place to reject the associated comdats referring to later associated comdats (associated comdats referring to associated comdats is invalid per COFF spec) that, so reject those. (A later patch will reject associated comdats referring to earlier comdats.) Differential Revision: https://reviews.llvm.org/D56929 llvm-svn: 351917
* COFF, ELF: ICF: Perform 2 rounds of relocation hash propagation.Peter Collingbourne2019-01-221-9/+11
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | LLD's performance on PGO instrumented Windows binaries was still not great even with the fix in D56955; out of the 2m41s linker runtime, around 2 minutes were still being spent in ICF. I looked into this more closely and discovered that the vast majority of the runtime was being spent segregating .pdata sections with the following relocation chain: .pdata -> identical .text -> unique PGO counter (not eligible for ICF) This patch causes us to perform 2 rounds of relocation hash propagation, which allows the hash for the .pdata sections to incorporate the identifier from the PGO counter. With that, the amount of time spent in ICF was reduced to about 2 seconds. I also found that the same change led to a significant ICF performance improvement in a regular release build of Chromium's chrome_child.dll, where ICF time was reduced from around 1s to around 700ms. With the same change applied to the ELF linker, median of 100 runs for lld-speed-test/chrome reduced from 4.53s to 4.45s on my machine. I also experimented with increasing the number of propagation rounds further, but I did not observe any further significant performance improvements linking Chromium or Firefox. Differential Revision: https://reviews.llvm.org/D56986 llvm-svn: 351899
* COFF, ELF: Adjust ICF hash computation to account for self relocations.Peter Collingbourne2019-01-221-1/+1
| | | | | | | | | | | | | | | | It turns out that sections in PGO instrumented object files on Windows contain a large number of relocations pointing to themselves. With r347429 this can cause many sections to receive the same hash (usually zero) as a result of a section's hash being xor'ed with itself. This patch causes the COFF and ELF linkers to avoid this problem by adding the hash of the relocated section instead of xor'ing it. On my machine this causes the regressing test case provided by Mozilla to terminate in 2m41s. Differential Revision: https://reviews.llvm.org/D56955 llvm-svn: 351898
* Update the file headers across all of the LLVM projects in the monorepoChandler Carruth2019-01-1928-112/+84
| | | | | | | | | | | | | | | | | to reflect the new license. We understand that people may be surprised that we're moving the header entirely to discuss the new license. We checked this carefully with the Foundation's lawyer and we believe this is the correct approach. Essentially, all code in the project is now made available by the LLVM project under our new license, so you will see that the license headers include that license only. Some of our contributors have contributed code under our old license, and accordingly, we have retained a copy of our old license notice in the top-level files in each project and repository. llvm-svn: 351636
* lld-link: Spelling fixes in comments and minor style tweaksNico Weber2019-01-143-9/+12
| | | | | | | | | | | | | | Changes a few things I noticed while reading this code. - fix a few typos in comments - remove two `auto` uses where the type wasn't clear to me - add comment saying that two sequential checks for `if (SparseChunks[SectionNumber] == PendingComdat)` are intentional - name two parameters No behavior change. Differential Revision: https://reviews.llvm.org/D56677 llvm-svn: 351101
* Fix unchecked Error introduced in r350956Alexandre Ganea2019-01-111-1/+3
| | | | llvm-svn: 350968
* [LLD][COFF] Support /ignore:4099. Support /ignore with comma-separated ↵Alexandre Ganea2019-01-113-7/+16
| | | | | | | | arguments. Differential Revision: https://reviews.llvm.org/D56392 llvm-svn: 350956
* lld-link: Add help strings for /manifest, /nodefaultlib, /noentry; tweak ↵Nico Weber2019-01-091-9/+17
| | | | | | | | | | | manifest help strings My main motivation is that I can never remember /nodefaultlib and `lld-link /? | grep no` didn't display it due to it not having a help string. Differential Revision: https://reviews.llvm.org/D56502 llvm-svn: 350750
* [CodeView] More appropriate name and type for a Microsoft precompiled ↵Alexandre Ganea2019-01-072-6/+6
| | | | | | headers parameter. NFC llvm-svn: 350520
* [LLD][COFF] PDB: Parallel sort publicsAlexandre Ganea2019-01-051-4/+5
| | | | | | | | | | | | | | | | Saves up to 1.3 sec on large PDBs. Figures below are for the "Globals Stream Layout" pass: Before This patch Large EXE (PDB is ~2 GB) 3330 ms 2022 ms Large EXE (PDB is ~2 GB) 2680 ms 1608 ms Large DLL (PDB is ~1 GB) 1455 ms 938 ms Large DLL (PDB is ~800 MB) 1215 ms 800 ms Small DLL (PDB is ~200 MB) 224 ms 146 ms Differential Revision: https://reviews.llvm.org/D56334 llvm-svn: 350452
* [LLD][COFF] Fix namespace compilation issue with a upcoming patch. NFCAlexandre Ganea2019-01-051-4/+4
| | | | llvm-svn: 350450
* [LLD][COFF] Fix file/line retrieval when a undefined symbol is to be printedAlexandre Ganea2019-01-041-7/+13
| | | | | | Differential Revision: https://reviews.llvm.org/D55951 llvm-svn: 350438
* [COFF] Set the CPU string for LTO like ELF doesReid Kleckner2018-12-181-0/+1
| | | | | | Fixes PR40043 llvm-svn: 349436
* [codeview] Align symbol records to save 441MB during linking clang.pdbReid Kleckner2018-12-181-4/+6
| | | | | | | | | | | | | | | | | | | | In PDBs, symbol records must be aligned to four bytes. However, in the object file, symbol records may not be aligned. MSVC does not pad out symbol records to make sure they are aligned. That means the linker has to do extra work to insert the padding. Currently, LLD calculates the required space with alignment, and copies each record one at a time while padding them out to the correct size. It has a fast path that avoids this copy when the records are already aligned. This change fixes a bug in that codepath so that the copy is actually saved, and tweaks LLVM's symbol record emission to align symbol records. Here's how things compare when doing a plain clang Release+PDB build: - objs are 0.65% bigger (negligible) - link is 3.3% faster (negligible) - saves allocating 441MB - new LLD high water mark is ~1.05GB llvm-svn: 349431
* Correctly handle skewed streams in drop_front() method.Zachary Turner2018-12-131-1/+4
| | | | | | | | | | | | When calling BinaryStreamArray::drop_front(), if the stream is skewed it means we must never drop the first bytes of the stream since offsets which occur in records assume the existence of those bytes. So if we want to skip the first record in a stream, then what we really want to do is just set the begin pointer to the next record. But we shouldn't actually remove those bytes from the underlying view of the data. llvm-svn: 349066
* [PDB] Move some code around. NFC.Zachary Turner2018-12-061-34/+2
| | | | llvm-svn: 348505
* [PDB] Emit S_UDT records in LLD.Zachary Turner2018-12-041-11/+9
| | | | | | | | | | | Previously these were dropped. We now understand them sufficiently well to start emitting them. From the debugger's perspective, this now enables us to have debug info about typedefs (both global and function-locally scoped) Differential Revision: https://reviews.llvm.org/D55228 llvm-svn: 348306
* [PDB] Quote linker arguments containing spaces (mimic MSVC)Alexandre Ganea2018-11-301-1/+27
| | | | | | | | Initial patch by Will Wilson (@lantictac) Differential Revision: https://reviews.llvm.org/D55074 llvm-svn: 348001
* Do not assume .idata is zero-initialized.Rui Ueyama2018-11-302-0/+3
| | | | | | | | | | | | | We initialize .text section with 0xcc (INT3 instruction), so we need to explicitly write data even if it is zero if it can be in a .text section. If you specify /merge:.rdata=.text, .rdata (which contains .idata) is put to .text, so we need to do this. Fixes https://bugs.llvm.org/show_bug.cgi?id=39826 Differential Revision: https://reviews.llvm.org/D55098 llvm-svn: 348000
* [COFF] Remove empty sections before calculating the size of section headersMartin Storsjo2018-11-271-0/+17
| | | | | | | | | | | | | The number of sections is used in assignAddresses (in finalizeAddresses) and the space for all sections is permanent from that point on, even if we later decide we won't write some of them. The VirtualSize field also gets calculated in assignAddresses, so we need to manually check whether the section is empty here instead. Differential Revision: https://reviews.llvm.org/D54495 llvm-svn: 347704
* [PDB] Add symbol records in bulkReid Kleckner2018-11-271-31/+85
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: This speeds up linking clang.exe/pdb with /DEBUG:GHASH by 31%, from 12.9s to 9.8s. Symbol records are typically small (16.7 bytes on average), but we processed them one at a time. CVSymbol is a relatively "large" type. It wraps an ArrayRef<uint8_t> with a kind an optional 32-bit hash, which we don't need. Before this change, each DbiModuleDescriptorBuilder would maintain an array of CVSymbols, and would write them individually with a BinaryItemStream. With this change, we now add symbols that happen to appear contiguously in bulk. For each .debug$S section (roughly one per function), we allocate two copies, one for relocation, and one for realignment purposes. For runs of symbols that go in the module stream, which is most symbols, we now add them as a single ArrayRef<uint8_t>, so the vector DbiModuleDescriptorBuilder is roughly linear in the number of .debug$S sections (O(# funcs)) instead of the number of symbol records (very large). Some stats on symbol sizes for the curious: PDB size: 507M sym bytes: 316,508,016 sym count: 18,954,971 sym byte avg: 16.7 As future work, we may be able to skip copying symbol records in the linker for realignment purposes if we make LLVM write them aligned into the object file. We need to double check that such symbol records are still compatible with link.exe, but if so, it's definitely worth doing, since my profile shows we spend 500ms in memcpy in the symbol merging code. We could potentially cut that in half by saving a copy. Alternatively, we could apply the relocations *after* we iterate the symbols. This would require some careful re-engineering of the relocation processing code, though. Reviewers: zturner, aganea, ruiu Subscribers: hiraditya, llvm-commits Differential Revision: https://reviews.llvm.org/D54554 llvm-svn: 347687
* [COFF] Generate a codeview build id signature for MinGW even when not ↵Martin Storsjo2018-11-271-1/+18
| | | | | | | | | | | | | | | | | | creating a PDB GNU ld, which doesn't generate PDBs, can optionally generate a build id by passing the --build-id option. LLD's MinGW frontend knows about this option but ignores it, as I had falsely assumed that LLD already generated build IDs even in those cases. If debug info is requested and no PDB path is set, generate a build id signature as a hash of the binary itself. This allows associating a binary to a minidump, even if debug info isn't written in PDB form by the linker. Differential Revision: https://reviews.llvm.org/D54828 llvm-svn: 347645
* [COFF] Add exported functions to gfids table for /guard:cfReid Kleckner2018-11-271-12/+25
| | | | | | | | | | | | | | | | | | | | | | | Summary: MSVC does this, and we should to. The .gfids table is a table of RVAs, so it's impossible for a DLL to indicate that an imported symbol is address taken. Therefore, exports appear to be listed as address taken by the DLL that exports them. This fixes an issue that Firefox ran into here: https://bugzilla.mozilla.org/show_bug.cgi?id=1485016#c12 In Firefox, the export directive came from a .def file, but we need to do this for any kind of export. Reviewers: dmajor, hans, amccarth, alex Subscribers: llvm-commits Differential Revision: https://reviews.llvm.org/D54723 llvm-svn: 347623
* [COFF] ICF: use parallelForEach{,N}Fangrui Song2018-11-261-4/+5
| | | | | | | | | | | | | | Summary: They have an additional `ThreadsEnabled` check, which does not matter much. Reviewers: pcc, ruiu, rnk Reviewed By: ruiu Subscribers: llvm-commits Differential Revision: https://reviews.llvm.org/D54812 llvm-svn: 347587
* COFF: ICF: Include contents of referenced sections in initial partitioning ↵Peter Collingbourne2018-11-211-1/+11
| | | | | | | | | | | | | | | | | | | | | | hash. NFCI. Previously we were taking over 13 minutes to link Firefox's xul.dll on ARM64; this reduces link time to around 18s on my machine. The root cause of the problem was that all of the input .pdata sections had the same unrelocated section data and therefore the same hash, which made segregation quadratic in the number of .pdata sections. The reason why we weren't observing this on other architectures was that ARM has a different .pdata format. On non-ARM the format is (start address, end address, .xdata), which caused the size of the function to appear in the unrelocated section data where the end address field is. However, the ARM format omits the end address field. Fixes PR39667. Differential Revision: https://reviews.llvm.org/D54809 llvm-svn: 347429
* [CodeView] RelocPtr points to little endian data.Zachary Turner2018-11-201-1/+1
| | | | | | | | | | Don't use a uint32_t*, use a ulittle32_t* to make this correct on big endian systems. Patch by James Clarke Differential Revision: https://reviews.llvm.org/D54421 llvm-svn: 347349
* [COFF] Fix a longstanding typo in a variable name. NFC.Martin Storsjo2018-11-141-5/+5
| | | | llvm-svn: 346846
* [PDB] Simplify symbol handling code, NFCReid Kleckner2018-11-131-25/+22
| | | | | | | | | | | | | | | | | - Make mergeSymbolRecords a method of PDBLinker to reduce the number of parameters it needs. - Remove a stale FIXME comment about error handling. We already drop unknown symbol records, log them, and continue. - Update a comment about why we're copying the symbol record. We do it to realign the record. We can already mutate the symbol record memory, it's memory allocated by relocateDebugChunk. - Avoid the extra `CVSymbol NewSym` variable. We can mutate Sym in place, which is best, since we're mutating the underlying record anyway. llvm-svn: 346817
* [COFF] Simplify relocation to discarded section diagnostic code, NFCReid Kleckner2018-11-131-29/+36
| | | | | | Move it out of the loop that applies relocations for readability. llvm-svn: 346777
* [PDB] Simplify some ghash code, NFCReid Kleckner2018-11-101-17/+21
| | | | | | | Instead of calling the same function twice with different parameters, make the parameters depend on the condition. llvm-svn: 346578
* Fix -Wextra-qualification warningReid Kleckner2018-11-081-1/+1
| | | | llvm-svn: 346431
* [COFF] Improve relocation against discarded section errorReid Kleckner2018-11-083-3/+7
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: Reuse the "referenced by" note diagnostic code that we already use for undefined symbols. In my case, it turned this: lld-link: error: relocation against symbol in discarded section: .text lld-link: error: relocation against symbol in discarded section: .text ... Into this: lld-link: error: relocation against symbol in discarded section: .text >>> referenced by libANGLE.lib(CompilerGL.obj):(.SCOVP$M) >>> referenced by libANGLE.lib(CompilerGL.obj):(.SCOVP$M) ... lld-link: error: relocation against symbol in discarded section: .text >>> referenced by obj/third_party/angle/libGLESv2/entry_points_egl_ext.obj:(.SCOVP$M) >>> referenced by obj/third_party/angle/libGLESv2/entry_points_egl_ext.obj:(.SCOVP$M) ... I think the new output is more useful. Reviewers: ruiu, pcc Subscribers: llvm-commits Differential Revision: https://reviews.llvm.org/D54240 llvm-svn: 346427
* [LLD] Fix Microsoft precompiled headers cross-compile on LinuxAlexandre Ganea2018-11-082-31/+26
| | | | | | Differential revision: https://reviews.llvm.org/D54122 llvm-svn: 346403
* Fix build breakerage on GCC 5.4:Alexandre Ganea2018-11-051-1/+1
| | | | | | | | | | /home/buildslave/slave_as-bldslv8/lld-perf-testsuite/llvm/tools/lld/COFF/PDB.cpp:365:51: error: 'auto' not allowed in lambda parameter auto DbgIt = find_if(File->getDebugChunks(), [](auto &C) { ^~~~ http://lab.llvm.org:8011/builders/lld-perf-testsuite/builds/8717/steps/build-bin%2Flld/logs/stdio llvm-svn: 346160
* [COFF][LLD] Add link support for Microsoft precompiled headers OBJsAlexandre Ganea2018-11-052-36/+263
| | | | | | | | | | | This change allows for link-time merging of debugging information from Microsoft precompiled types OBJs compiled with cl.exe /Z7 /Yc and /Yu. This fixes llvm.org/PR34278 Differential Revision: https://reviews.llvm.org/D45213 llvm-svn: 346154
OpenPOWER on IntegriCloud