summaryrefslogtreecommitdiff
path: root/lld/COFF/Symbols.h
Commit message (Collapse)AuthorAgeFilesLines
* [lld][COFF] Add support for overriding weak symbols in LLVM bitcode inputAlan Zhao2022-09-081-2/+9
| | | | | | | | | | | | | | | | | LLVM bitcode contains support for weak symbols, so we can add support for overriding weak symbols in the output COFF even though COFF doesn't have inherent support for weak symbols. The motivation for this patch is that Chromium is trying to use libc++'s assertion handler mechanism, which relies on weak symbols [0], but we're unable to perform a ThinLTO build on Windows due to this problem [1]. [0]: https://reviews.llvm.org/D121478 [1]: https://crrev.com/c/3863576 Reviewed By: rnk Differential Revision: https://reviews.llvm.org/D133165
* [LLD][COFF] Fix writing a map file when range extension thunks are insertedJan Ole Hüser2022-09-071-1/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Bug: An assertion fails: Assertion failed: isa<To>(Val) && "cast<Ty>() argument of incompatible type!", file C:\Users\<user>\prog\llvm\llvm-git-lld-bug\llvm\include\llvm/Support/Casting.h, line 578 Bug is triggered, if - a map file is requested with /MAP, and - Architecture is ARMv7, Thumb, and - a relative jump (branch instruction) is greater than 16 MiB (2^24) The reason for the Bug is: - a Thunk is created for the jump - a Symbol for the Thunk is created - of type `DefinedSynthetic` - in file `Writer.cpp` - in function `getThunk` - the Symbol has no name - when creating the map file, the name of the Symbol is queried - the function `Symbol::computeName` of the base class `Symbol` casts the `this` pointer to type `DefinedCOFF` (a derived type), but the acutal type is `DefinedSynthetic` - The in the llvm::cast an assertion fails Changes: - Modify regression test to trigger this bug - Give the symbol pointing to the thunk a name, to fix the bug - Add assertion, that only DefinedCOFF symbols are allowed to have an empty name, when the constructor of the base class Symbol is executed Reviewed By: rnk Differential Revision: https://reviews.llvm.org/D133201
* [lld-link] Replace LazyObjFile with lazy ObjFile/BitcodeFileFangrui Song2022-01-041-3/+2
| | | | | | | | | | | | | Similar to ELF 3a5fb57393c3bc77be9e7afc2ec9d4ec3c9bbf70. * previously when a LazyObjFile was extracted, a new ObjFile/BitcodeFile was created; now the file is reused, just with `lazy` cleared * avoid the confusing transfer of `symbols` from LazyObjFile to the new file * simpler code, smaller executable (5200+ bytes smaller on x86-64) * make eager parsing feasible (for parallel section/symbol table initialization) Reviewed By: aganea, rnk Differential Revision: https://reviews.llvm.org/D116434
* [LLD] [COFF] Add a couple "MinGW only" comments re linking against DLLs. NFC.Martin Storsjö2021-07-201-0/+1
| | | | This was requested in the post-commit review of D104530.
* [LLD] [COFF] Support linking directly against DLLs in MinGW modeMartin Storsjö2021-07-021-1/+18
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | GNU ld.bfd supports linking directly against DLLs without using an import library, and some projects have picked up on this habit. (There's no one single unsurmountable issue with using import libraries, but this is a regularly surfacing missing feature.) As long as one is linking by name (instead of by ordinal), the DLL export table contains most of the information needed. (One can inspect what section a symbol points at, to see if it's a function or data symbol. The practical implementation of this loops over all sections for each symbol, but as long as they're not very many, that should hopefully be tolerable performance wise.) One exception where the information in the DLL isn't entirely enough is on i386 with stdcall functions; depending on how they're done, the exported function name can be a plain undecorated name, while the import library would contain the full decorated symbol name. This issue is addressed separately in a different patch. This is implemented mimicing the structure of a regular import library, with one InputFile corresponding to the static archive that just adds lazy symbols, which then are fetched when they are needed. When such a symbol is fetched, we synthesize a coff_import_header structure in memory and create a regular ImportFile out of it. The implementation could be even smaller by just creating ImportFiles for every symbol available immediately, but that would have the drawback of actually ending up importing all symbols unless running with GC enabled (and mingw mode defaults to having it disabled for historical reasons). Differential Revision: https://reviews.llvm.org/D104530
* [CFGuard] Add address-taken IAT tables and delay-load supportAndrew Paverd2020-11-171-0/+7
| | | | | | | | | This patch adds support for creating Guard Address-Taken IAT Entry Tables (.giats$y sections) in object files, matching the behavior of MSVC. These contain lists of address-taken imported functions, which are used by the linker to create the final GIATS table. Additionally, if any DLLs are delay-loaded, the linker must look through the .giats tables and add the respective load thunks of address-taken imports to the GFIDS table, as these are also valid call targets. Reviewed By: rnk Differential Revision: https://reviews.llvm.org/D87544
* Revert "Reland [CFGuard] Add address-taken IAT tables and delay-load support"Hans Wennborg2020-11-111-7/+0
| | | | | | | | | | | | | | This broke both Firefox and Chromium (PR47905) due to what seems like dllimport function not being handled correctly. > This patch adds support for creating Guard Address-Taken IAT Entry Tables (.giats$y sections) in object files, matching the behavior of MSVC. These contain lists of address-taken imported functions, which are used by the linker to create the final GIATS table. > Additionally, if any DLLs are delay-loaded, the linker must look through the .giats tables and add the respective load thunks of address-taken imports to the GFIDS table, as these are also valid call targets. > > Reviewed By: rnk > > Differential Revision: https://reviews.llvm.org/D87544 This reverts commit cfd8481da1adba1952e0f6ecd00440986e49a946.
* Reapply [LLD] [COFF] Implement a GNU/ELF like -wrap optionMartin Storsjö2020-10-151-2/+14
| | | | | | | | | | | | | | | | | | | | | Add a simple forwarding option in the MinGW frontend, and implement the private -wrap option in the COFF linker. The feature in lld-link isn't gated by the -lldmingw option, but the option is left as a private, undocumented option primarily used by the MinGW driver. The implementation is significantly based on the support for --wrap in the ELF linker, but many small nuance details are different between the ELF and COFF linkers, ending up with more than a few implementation differences. This fixes https://bugs.llvm.org/show_bug.cgi?id=47384. Differential Revision: https://reviews.llvm.org/D89004 Reapplied with the bitfield member canInline fixed so it doesn't break builds targeting windows.
* Revert "[LLD] [COFF] Implement a GNU/ELF like -wrap option"Arthur Eubanks2020-10-151-14/+2
| | | | | | | | | This reverts commit a012c704b5e5b60f9d2a7304d27cbc84a3619571. Breaks Windows builds. C:\src\llvm-mint\lld\COFF\Symbols.cpp(26,1): error: static_assert failed due to requirement 'sizeof(lld::coff::SymbolUnion) <= 48' "symbols should be optimized for memory usage" static_assert(sizeof(SymbolUnion) <= 48,
* [LLD] [COFF] Implement a GNU/ELF like -wrap optionMartin Storsjö2020-10-151-2/+14
| | | | | | | | | | | | | | | | | | Add a simple forwarding option in the MinGW frontend, and implement the private -wrap option in the COFF linker. The feature in lld-link isn't gated by the -lldmingw option, but the option is left as a private, undocumented option primarily used by the MinGW driver. The implementation is significantly based on the support for --wrap in the ELF linker, but many small nuance details are different between the ELF and COFF linkers, ending up with more than a few implementation differences. This fixes https://bugs.llvm.org/show_bug.cgi?id=47384. Differential Revision: https://reviews.llvm.org/D89004
* Reland [CFGuard] Add address-taken IAT tables and delay-load supportAndrew Paverd2020-10-131-0/+7
| | | | | | | | | This patch adds support for creating Guard Address-Taken IAT Entry Tables (.giats$y sections) in object files, matching the behavior of MSVC. These contain lists of address-taken imported functions, which are used by the linker to create the final GIATS table. Additionally, if any DLLs are delay-loaded, the linker must look through the .giats tables and add the respective load thunks of address-taken imports to the GFIDS table, as these are also valid call targets. Reviewed By: rnk Differential Revision: https://reviews.llvm.org/D87544
* Revert "[CFGuard] Add address-taken IAT tables and delay-load support"Arthur Eubanks2020-10-011-7/+0
| | | | This reverts commit ef4e971e5e18ae796466623df8f26265ba6bdfb5.
* [CFGuard] Add address-taken IAT tables and delay-load supportAndrew Paverd2020-10-011-0/+7
| | | | | | | | | This patch adds support for creating Guard Address-Taken IAT Entry Tables (.giats$y sections) in object files, matching the behavior of MSVC. These contain lists of address-taken imported functions, which are used by the linker to create the final GIATS table. Additionally, if any DLLs are delay-loaded, the linker must look through the .giats tables and add the respective load thunks of address-taken imports to the GFIDS table, as these are also valid call targets. Reviewed By: rnk Differential Revision: https://reviews.llvm.org/D87544
* [COFF] Paritally inline Symbol::getName, NFCReid Kleckner2020-05-031-1/+15
|
* [LLD] [COFF] Fix post-commit suggestions for absolute symbol equalityMartin Storsjö2020-01-081-8/+1
| | | | Differential Revision: https://reviews.llvm.org/D72252
* [LLD] [COFF] Don't error out on duplicate absolute symbols with the same valueMartin Storsjö2020-01-041-0/+8
| | | | | | | | | Both MS link.exe and GNU ld.bfd handle it this way; one can have multiple object files defining the same absolute symbols, as long as it defines it to the same value. But if there are multiple absolute symbols with differing values, it is treated as an error. Differential Revision: https://reviews.llvm.org/D71981
* reland "[lld-link] implement -start-lib and -end-lib"Bob Haarman2019-09-031-15/+26
| | | | | | | | | | | | | | | | | | | | | | | | | | Summary: This is a re-land of r370487 with a fix for the use-after-free bug that rev contained. This implements -start-lib and -end-lib flags for lld-link, analogous to the similarly named options in ld.lld. Object files after -start-lib are included in the link only when needed to resolve undefined symbols. The -end-lib flag goes back to the normal behavior of always including object files in the link. This mimics the semantics of static libraries, but without needing to actually create the archive file. Reviewers: ruiu, smeenai, MaskRay Reviewed By: ruiu, MaskRay Subscribers: akhuang, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D66848 llvm-svn: 370816
* Revert "[lld-link] implement -start-lib and -end-lib"Vlad Tsyrklevich2019-08-301-26/+15
| | | | | | | This reverts commit r370487 as it is causing ASan/MSan failures on sanitizer-x86_64-linux-fast llvm-svn: 370550
* [lld-link] implement -start-lib and -end-libBob Haarman2019-08-301-15/+26
| | | | | | | | | | | | | | | | | | | | | | | Summary: This implements -start-lib and -end-lib flags for lld-link, analogous to the similarly named options in ld.lld. Object files after -start-lib are included in the link only when needed to resolve undefined symbols. The -end-lib flag goes back to the normal behavior of always including object files in the link. This mimics the semantics of static libraries, but without needing to actually create the archive file. Reviewers: ruiu, smeenai, MaskRay Reviewed By: ruiu, MaskRay Subscribers: akhuang, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D66848 llvm-svn: 370487
* [COFF] Add libcall symbols to the link when LTO is being usedAmy Huang2019-08-221-0/+2
| | | | llvm-svn: 369694
* ld.lld: Demangle symbols from archives in diagnosticsNico Weber2019-07-231-2/+8
| | | | | | | | | | | | | | | | | | | | | | | | | | | This ports r366573 from COFF to ELF. There are now to toString(Archive::Symbol), one doing MSVC demangling in COFF and one doing Itanium demangling in ELF, so rename these two to toCOFFString() and to toELFString() to not get a duplicate symbol. Nothing ever passes a raw Archive::Symbol to CHECK(), so these not being part of the normal toString() machinery seems ok. There are two code paths in the ELF linker that emits this type of diagnostic: 1. The "normal" one in InputFiles.cpp. This is covered by the tweaked test. 2. An additional one that's only used for libcalls if there's at least one bitcode in the link, and if the libcall symbol is lazy, and lazily loaded from an archive (i.e. not from a lazy .o file). (This code path was added in r339301.) Since all libcall names so far are C symbols and never mangled, the change there is not observable and hence not covered by tests. Differential Revision: https://reviews.llvm.org/D65095 llvm-svn: 366836
* lld-link: Demangle symbols from archives in diagnosticsNico Weber2019-07-191-0/+1
| | | | | | | | | Also add test coverage for thin archives (which are the only way I could come up with to test at least some of the diagnostic changes). Differential Revision: https://reviews.llvm.org/D64927 llvm-svn: 366573
* [Coding style change][lld] Rename variables for non-ELF portsRui Ueyama2019-07-111-114/+114
| | | | | | | | | | | This patch does the same thing as r365595 to other subdirectories, which completes the naming style change for the entire lld directory. With this, the naming style conversion is complete for lld. Differential Revision: https://reviews.llvm.org/D64473 llvm-svn: 365730
* Make functions and member variables distinguishable even after the name ↵Rui Ueyama2019-07-101-5/+1
| | | | | | style change. NFC. llvm-svn: 365605
* [COFF] Pack Name in Symbol as is done in ELFReid Kleckner2019-04-191-3/+7
| | | | | | | | | | | | | | | | | | | | | | Summary: This assumes all symbols are <4GB long, so we can store them as a 32-bit integer. This reorders the fields so the length appears first, packing with the other bitfield data in the base Symbol object. This saved 70MB / 3.60% of heap allocations when linking browser_tests.exe with no PDB. It's not much as a percentage, but worth doing. I didn't do performance measurements, I don't think it will be measurable in time. Reviewers: ruiu, inglorion, amccarth, aganea Subscribers: llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D60297 llvm-svn: 358794
* Update the file headers across all of the LLVM projects in the monorepoChandler Carruth2019-01-191-4/+3
| | | | | | | | | | | | | | | | | 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-141-1/+1
| | | | | | | | | | | | | | 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
* [COFF] Allow automatic dllimport from gnu import librariesMartin Storsjo2018-09-261-3/+3
| | | | | | | | | Don't assume that the IAT chunk will be a DefinedImportData, it can just as well be a DefinedRegular for gnu import libraries. Differential Revision: https://reviews.llvm.org/D52381 llvm-svn: 343069
* fix comment typoNico Weber2018-08-271-1/+1
| | | | llvm-svn: 340742
* [COFF] Support MinGW automatic dllimport of dataMartin Storsjo2018-08-271-0/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Normally, in order to reference exported data symbols from a different DLL, the declarations need to have the dllimport attribute, in order to use the __imp_<var> symbol (which contains an address to the actual variable) instead of the variable itself directly. This isn't an issue in the same way for functions, since any reference to the function without the dllimport attribute will end up as a reference to a thunk which loads the actual target function from the import address table (IAT). GNU ld, in MinGW environments, supports automatically importing data symbols from DLLs, even if the references didn't have the appropriate dllimport attribute. Since the PE/COFF format doesn't support the kind of relocations that this would require, the MinGW's CRT startup code has an custom framework of their own for manually fixing the missing relocations once module is loaded and the target addresses in the IAT are known. For this to work, the linker (originall in GNU ld) creates a list of remaining references needing fixup, which the runtime processes on startup before handing over control to user code. While this feature is rather controversial, it's one of the main features allowing unix style libraries to be used on windows without any extra porting effort. Some sort of automatic fixing of data imports is also necessary for the itanium C++ ABI on windows (as clang implements it right now) for importing vtable pointers in certain cases, see D43184 for some discussion on that. The runtime pseudo relocation handler supports 8/16/32/64 bit addresses, either PC relative references (like IMAGE_REL_*_REL32*) or absolute references (IMAGE_REL_AMD64_ADDR32, IMAGE_REL_AMD64_ADDR32, IMAGE_REL_I386_DIR32). On linking, the relocation is handled as a relocation against the corresponding IAT slot. For the absolute references, a normal base relocation is created, to update the embedded address in case the image is loaded at a different address. The list of runtime pseudo relocations contains the RVA of the imported symbol (the IAT slot), the RVA of the location the relocation should be applied to, and a size of the memory location. When the relocations are fixed at runtime, the difference between the actual IAT slot value and the IAT slot address is added to the reference, doing the right thing for both absolute and relative references. With this patch alone, things work fine for i386 binaries, and mostly for x86_64 binaries, with feature parity with GNU ld. Despite this, there are a few gotchas: - References to data from within code works fine on both x86 architectures, since their relocations consist of plain 32 or 64 bit absolute/relative references. On ARM and AArch64, references to data doesn't consist of a plain 32 or 64 bit embedded address or offset in the code. On ARMNT, it's usually a MOVW+MOVT instruction pair represented by a IMAGE_REL_ARM_MOV32T relocation, each instruction containing 16 bit of the target address), on AArch64, it's usually an ADRP+ADD/LDR/STR instruction pair with an even more complex encoding, storing a PC relative address (with a range of +/- 4 GB). This could theoretically be remedied by extending the runtime pseudo relocation handler with new relocation types, to support these instruction encodings. This isn't an issue for GCC/GNU ld since they don't support windows on ARMNT/AArch64. - For x86_64, if references in code are encoded as 32 bit PC relative offsets, the runtime relocation will fail if the target turns out to be out of range for a 32 bit offset. - Fixing up the relocations at runtime requires making sections writable if necessary, with the VirtualProtect function. In Windows Store/UWP apps, this function is forbidden. These limitations are addressed by a few later patches in lld and llvm. Differential Revision: https://reviews.llvm.org/D50917 llvm-svn: 340726
* [COFF] Fix a comment about automatic resolving of dllimports from within a ↵Martin Storsjo2018-08-071-2/+2
| | | | | | | | module. NFC. Differential Revision: https://reviews.llvm.org/D50357 llvm-svn: 339100
* Remove an unused accessor and simplify the logic a bit. NFC.Rui Ueyama2018-02-171-5/+4
| | | | llvm-svn: 325445
* Revert r325158: Convert an assert to a static_assert. NFC.Rui Ueyama2018-02-141-2/+2
| | | | | | This reverts commit r325158 because it broke GCC builds. llvm-svn: 325183
* Convert an assert to a static_assert. NFC.Sam Clegg2018-02-141-2/+2
| | | | | | Differential Revision: https://reviews.llvm.org/D43305 llvm-svn: 325158
* Check that Symbol types are trivially destructibleSam Clegg2018-02-131-0/+2
| | | | | | | | | | | | | | This adds an extra level of static safety to our use of placement new to allocate Symbol types. It prevents the accidental addition on a non-trivially-destructible member that could allocate and leak memory. From the spec: Storage occupied by trivially destructible objects may be reused without calling the destructor. Differential Revision: https://reviews.llvm.org/D43244 llvm-svn: 325025
* Move Memory.{h,cpp} to Common.Rui Ueyama2017-11-281-1/+1
| | | | | | Differential Revision: https://reviews.llvm.org/D40571 llvm-svn: 319221
* Reland r319090, "COFF: Do not create SectionChunks for discarded comdat ↵Peter Collingbourne2017-11-281-1/+0
| | | | | | | | | | | | | | sections." with a fix for debug sections. If /debug was not specified, readSection will return a null pointer for debug sections. If the debug section is associative with another section, we need to make sure that the section returned from readSection is not a null pointer before adding it as an associative section. Differential Revision: https://reviews.llvm.org/D40533 llvm-svn: 319133
* Revert r319090, "COFF: Do not create SectionChunks for discarded comdat ↵Peter Collingbourne2017-11-271-0/+1
| | | | | | | | | sections." Caused test failures in check-cfi on Windows. http://lab.llvm.org:8011/builders/sanitizer-windows/builds/20284 llvm-svn: 319100
* COFF: Do not create SectionChunks for discarded comdat sections.Peter Collingbourne2017-11-271-1/+0
| | | | | | | | | | | | | | | | | | | | With this change, instead of creating a SectionChunk for each section in the object file, we only create them when we encounter a prevailing comdat section. Also change how symbol resolution occurs between comdat symbols. Now only the comdat leader participates in comdat resolution, and not any other external associated symbols. This is more in line with how COFF semantics are defined, and should allow for a more straightforward implementation of non-ANY comdat types. On my machine, this change reduces our runtime linking a release build of chrome_child.dll with /nopdb from 5.65s to 4.54s (median of 50 runs). Differential Revision: https://reviews.llvm.org/D40238 llvm-svn: 319090
* COFF: Emit a COFF symbol table if /debug:dwarf is specified.Peter Collingbourne2017-11-211-1/+6
| | | | | | | | | This effectively reverts r318548 and r318635 while keeping the functionality behind the flag and preserving the bug fix from r318548. Differential Revision: https://reviews.llvm.org/D40264 llvm-svn: 318721
* COFF: Remove unused fields. NFC.Peter Collingbourne2017-11-201-6/+1
| | | | llvm-svn: 318635
* Remove a std::map and std::set that show up in LLD profilesReid Kleckner2017-11-131-1/+5
| | | | | | | | | | | | | | | | | | For GC roots, add a bit to SymbolBody to ensure that we don't add the same root twice, and switch to a vector. In addition to being faster, this may also fix some latent non-determinism. We iterate the GCRoot list later and it the order should be deterministic. For fixupExports, we can just use DenseMap. This is a simple string uniquing task, and we don't iterate the map. Reviewers: ruiu Subscribers: llvm-commits Differential Revision: https://reviews.llvm.org/D39609 llvm-svn: 318072
* Rename replaceBody -> replaceSymbol.Rui Ueyama2017-11-031-1/+1
| | | | llvm-svn: 317383
* Rename SymbolBody -> SymbolRui Ueyama2017-11-031-30/+27
| | | | | | | | | | | | | Now that we have only SymbolBody as the symbol class. So, "SymbolBody" is a bit strange name now. This is a mechanical change generated by perl -i -pe s/SymbolBody/Symbol/g $(git grep -l SymbolBody lld/ELF lld/COFF) nd clang-format-diff. Differential Revision: https://reviews.llvm.org/D39459 llvm-svn: 317370
* Remove a redundant union member.Rui Ueyama2017-10-311-10/+9
| | | | | | | This removes DefinedCOFF from SymbolUnion because DefinedCOFF is not a leaf class. Pointed out by pcc. llvm-svn: 317013
* [COFF] Merge Symbol and SymbolBody.Rui Ueyama2017-10-311-42/+27
| | | | llvm-svn: 317007
* Move new lld's code to Common subdirectory.Rui Ueyama2017-10-021-1/+1
| | | | | | | | | | New lld's files are spread under lib subdirectory, and it isn't easy to find which files are actually maintained. This patch moves maintained files to Common subdirectory. Differential Revision: https://reviews.llvm.org/D37645 llvm-svn: 314719
* [COFF] Add support for aligncomm directivesMartin Storsjo2017-08-141-1/+1
| | | | | | | | | | | | | | These are emitted for comm symbols in object files, when targeting a GNU environment. Alternatively, just ignore them since we already align CommonChunk to the natural size of the content (up to 32 bytes). That would only trade away the possibility to overalign small symbols, which doesn't sound like something that might not need to be handled? Differential Revision: https://reviews.llvm.org/D36304 llvm-svn: 310871
* [PDB] Write public symbol records and the publics hash tableReid Kleckner2017-07-271-4/+8
| | | | | | | | | | | | | | Summary: MSVC link.exe records all external symbol names in the publics stream. It provides similar functionality to an ELF .symtab. Reviewers: zturner, ruiu Subscribers: hiraditya, llvm-commits Differential Revision: https://reviews.llvm.org/D35871 llvm-svn: 309303
* Rename ObjectFile ObjFile for COFF as well.Rui Ueyama2017-07-261-1/+1
| | | | llvm-svn: 309228
View Lorry Controller Status