summaryrefslogtreecommitdiffstats
path: root/lld/COFF/InputFiles.cpp
Commit message (Collapse)AuthorAgeFilesLines
* [LLD][COFF] Enable linking of __declspec(selectany) symbols from Clang and GCCMarkus Böck2020-01-231-0/+11
| | | | | | | | | | | | When annotating a symbol with __declspec(selectany), Clang assigns it comdat 2 while GCC assigns it comdat 3. This patch enables two object files that contain a __declspec(selectany) symbol, one created by gcc and the other by clang, to be linked together instead of issuing a duplicate symbol error. Differential Revision: https://reviews.llvm.org/D73139 (cherry picked from commit 9dbc1ab23268abce5db98ad9a1e3aef89c371524)
* [lld] Fix -Wrange-loop-analysis warningsFangrui Song2020-01-011-4/+1
| | | | | | | | | | One instance looks like a false positive: lld/ELF/Relocations.cpp:1622:14: note: use reference type 'const std::pair<ThunkSection *, uint32_t> &' (aka 'cons t pair<lld::elf::ThunkSection *, unsigned int> &') to prevent copying for (const std::pair<ThunkSection *, uint32_t> ts : isd->thunkSections) It is not changed in this commit.
* [COFF] Avoid CodeView include in headerReid Kleckner2019-11-141-1/+2
| | | | | Most LLD/COFF files don't care about CodeView. Avoid using CodeView types in InputFiles.h.
* Forward declare the DWARFCache to avoid including LLVM DWARF detailsReid Kleckner2019-11-141-0/+1
| | | | | LLD's DWARF.h header leaks a lot of LLVM DWARF includes that LLD doesn't need. For Chunks.cpp, I see a compile time decrease of 3.1s to 2.7s.
* [COFF] Don't include llvm/LTO/LTO.h in a headerReid Kleckner2019-11-141-0/+7
| | | | | LLVM's LTO header includes all of llvm/IR, which most of the COFF linker doesn't need.
* [LLD] [COFF] Use the local dwarf code instead of Symbolizer for resolving ↵Martin Storsjo2019-10-211-0/+13
| | | | | | | | | | | | code locations. NFC. As we now have code that parses the dwarf info for variable locations, we can use that instead of relying on the higher level Symbolizer library, reducing the previous two different dwarf codepaths into one. Differential Revision: https://reviews.llvm.org/D69198 llvm-svn: 375391
* [LLD] Move duplicated dwarf parsing code to the Common library. NFC.Martin Storsjo2019-10-211-69/+4
| | | | | | Differential Revision: https://reviews.llvm.org/D69197 llvm-svn: 375390
* [LLD] [COFF] Try to report source locations for duplicate symbolsMartin Storsjo2019-10-181-2/+86
| | | | | | | | | | | | | | | | | | | | | | | This fixes the second part of PR42407. For files with dwarf debug info, it manually loads and iterates .debug_info to find the declared location of variables, to allow reporting them. (This matches the corresponding code in the ELF linker.) For functions, it uses the existing getFileLineDwarf which uses LLVMSymbolizer for translating addresses to file lines. In object files with codeview debug info, only the source location of duplicate functions is printed. (And even there, only for the first input file. The getFileLineCodeView function requires the object file to be fully loaded and initialized to properly resolve source locations, but duplicate symbols are reported at a stage when the second object file isn't fully loaded yet.) Differential Revision: https://reviews.llvm.org/D68975 llvm-svn: 375218
* [COFF] Wrap definitions in namespace lld { namespace coff {. NFCFangrui Song2019-10-101-17/+19
| | | | | | | | | | | Similar to D67323, but for COFF. Many lld/COFF/ files already use `namespace lld { namespace coff {`. Only a few need changing. Reviewed By: ruiu Differential Revision: https://reviews.llvm.org/D68772 llvm-svn: 374314
* dummy comment typo fix commit to cycle the botsNico Weber2019-10-101-2/+2
| | | | llvm-svn: 374270
* reland "[lld-link] implement -start-lib and -end-lib"Bob Haarman2019-09-031-8/+54
| | | | | | | | | | | | | | | | | | | | | | | | | | 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-54/+8
| | | | | | | 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-8/+54
| | | | | | | | | | | | | | | | | | | | | | | 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
* [LLD] [COFF] Support merging resource object filesMartin Storsjo2019-08-301-4/+6
| | | | | | | | | | | | | | | | | | | | | | | | Extend WindowsResourceParser to support using a ResourceSectionRef for loading resources from an object file. Only allow merging resource object files in mingw mode; keep the existing error on multiple resource objects in link mode. If there only is one resource object file and no .res resources, don't parse and recreate the .rsrc section, but just link it in without inspecting it. This allows users to produce any .rsrc section (outside of what the parser supports), just like before. (I don't have a specific need for this, but it reduces the risk of this new feature.) Separate out the .rsrc section chunks in InputFiles.cpp, and only include them in the list of section chunks to link if we've determined that there only was one single resource object. (We need to keep other chunks from those object files, as they can legitimately contain other sections as well, in addition to .rsrc section chunks.) Differential Revision: https://reviews.llvm.org/D66824 llvm-svn: 370436
* ld.lld: Demangle symbols from archives in diagnosticsNico Weber2019-07-231-2/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | 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-5/+4
| | | | | | | | | 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
* [COFF] Rename variale references in comments after VariableName -> ↵Fangrui Song2019-07-161-4/+4
| | | | | | variableName change llvm-svn: 366193
* Fix odd variable names.Rui Ueyama2019-07-121-1/+1
| | | | llvm-svn: 365875
* [lld-link] implement -thinlto-{prefix,object-suffix}-replaceBob Haarman2019-07-111-0/+11
| | | | | | | | | | | | | | | | | | | | | | | | | Summary: Adds the following two options to lld-link: -thinlto-prefix-replace: allows replacing a prefix in paths generated for ThinLTO. This can be used to ensure index files and native object files are stored in unique directories, allowing multiple distributed ThinLTO links to proceed concurrently. -thinlto-object-suffix-replace: allows replacing a suffix in object file paths involved in ThinLTO. This allows minimized index files to be used for the thin link while storing the paths to the full bitcode files for subsequent steps (code generation and final linking). Reviewers: ruiu, tejohnson, pcc, rnk Subscribers: mehdi_amini, steven_wu, dexonsmith, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D64542 llvm-svn: 365807
* [Coding style change][lld] Rename variables for non-ELF portsRui Ueyama2019-07-111-403/+403
| | | | | | | | | | | 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-1/+1
| | | | | | style change. NFC. llvm-svn: 365605
* [COFF] Handle .eh_frame$symbol as associative comdat for MinGWMartin Storsjo2019-06-141-3/+6
| | | | | | | | | | | | | This matches how it is done for .xdata and .pdata already. On i386, the symbol name in the section name suffix does not contain the extra underscore prefix. This is one part of a fix for PR42217. Differential Revision: https://reviews.llvm.org/D63350 llvm-svn: 363456
* lld/coff: slightly simplify ImportFile::parse()Nico Weber2019-06-141-2/+1
| | | | llvm-svn: 363397
* lld-link: Reject more than one resource .obj fileNico Weber2019-06-111-1/+6
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Users are exepcted to pass all .res files to the linker, which then merges all the resource in all .res files into a tree structure and then converts the final tree structure to a .obj file with .rsrc$01 and .rsrc$02 sections and then links that. If the user instead passes several .obj files containing such resources, the correct thing to do would be to have custom code to merge the trees in the resource sections instead of doing normal section merging -- but link.exe rejects if multiple resource obj files are passed in with LNK4078, so let lld-link do that too instead of silently writing broken .rsrc sections in that case. The only real way to run into this is if users manually convert .res files to .obj files by running cvtres and then handing the resulting .obj files to lld-link instead, which in practice likely never happens. (lld-link is slightly stricter than link.exe now: If link.exe is passed one .obj file created by cvtres, and a .res file, for some reason it just emits a warning instead of an error and outputs strange looking data. lld-link now errors out on mixed input like this.) One way users could accidentally run into this is the following scenario: If a .res file is passed to lib.exe, then lib.exe calls cvtres.exe on the .res file before putting it in the output .lib. (llvm-lib currently doesn't do this.) link.exe's /wholearchive seems to only add obj files referenced from the static library index, but lld-link current really adds all files in the archive. So if lld-link /wholearchive is used with .lib files produced by lib.exe and .res files were among the files handed to lib.exe, we previously silently produced invalid output, but now we error out. link.exe's /wholearchive semantics on the other hand mean that it wouldn't load the resource object files from the .lib file at all. Since this scenario is probably still an unlikely corner case, the difference in behavior here seems fine -- and lld-link might have to change to use link.exe's /wholearchive semantics in the future anyways. Vaguely related to PR42180. Differential Revision: https://reviews.llvm.org/D63109 llvm-svn: 363078
* [Object] Change ObjectFile::getSectionContents to return ↵Fangrui Song2019-05-141-1/+1
| | | | | | | | | | | | | | | | | | | Expected<ArrayRef<uint8_t>> Change std::error_code getSectionContents(DataRefImpl, StringRef &) const; to Expected<ArrayRef<uint8_t>> getSectionContents(DataRefImpl) const; Many object formats use ArrayRef<uint8_t> as the underlying type, which is generally better than StringRef to represent binary data, so change the type to decrease the number of type conversions. Reviewed By: ruiu, sbc100 Differential Revision: https://reviews.llvm.org/D61781 llvm-svn: 360648
* [Object] Change getSectionName() to return Expected<StringRef>Fangrui Song2019-05-021-3/+6
| | | | | | | | | | Summary: It currently receives an output parameter and returns std::error_code. Expected<StringRef> fits for this purpose perfectly. Differential Revision: https://reviews.llvm.org/D61421 llvm-svn: 359774
* [COFF] Don't emit .gfids sections when CFG is offReid Kleckner2019-04-241-2/+2
| | | | | | | Put them on the list of GuardFidChunks instead of the main Chunks list, even with CFG is off. It will be ignored if CFG is disabled. llvm-svn: 359137
* [LLD][COFF] use offset in archive to disambiguate archive membersBob Haarman2019-04-151-2/+19
| | | | | | | | | | | | | | | | | | | | | Summary: Archives can contain multiple members with the same name. This would cause ThinLTO links to fail ("Expected at most one ThinLTO module per bitcode file"). This change implements the same strategy we use in the ELF linker: make the offset in the archive part of the module name so that names are unique. Reviewers: pcc, mehdi_amini, ruiu Reviewed By: ruiu Subscribers: eraman, steven_wu, dexonsmith, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D60549 llvm-svn: 358440
* [LLD][COFF] Early dependency detectionAlexandre Ganea2019-04-011-0/+56
| | | | | | | | | | | | We introduce a new class hierarchy for debug types merging (in DebugTypes.h). The end-goal is to parallelize the type merging - please see the plan in D59226. Previously, dependency discovery was done on the fly, much later, during the type merging loop. Unfortunately, parallelizing the type merging requires the dependencies to be merged in first, before any dependent ObjFile, thus this early discovery. The overall intention for this path is to discover debug information dependencies at a much earlier stage, when processing input files. Currently, two types of dependency are supported: PDB type servers (when compiling with MSVC /Zi) and precompiled headers OBJs (when compiling with MSVC /Yc and /Yu). Once discovered, an explicit link is added into the dependent ObjFile, through the new debug types class hierarchy introduced in DebugTypes.h. Differential Revision: https://reviews.llvm.org/D59053 llvm-svn: 357383
* Don't copy the .drective section with std::stringReid Kleckner2019-03-291-1/+1
| | | | | | Both COFF and bitcode input files expose these as stable strings. llvm-svn: 357314
* [LLD][COFF] Generate import modules & COFF groups in PDBAlexandre Ganea2019-03-291-1/+1
| | | | | | | | | | | | Generate import modules for each imported DLL, along with its symbol stream. Also create COFF groups in the * Linker * module, one for each PartialSection (input, unmerged sections) Currently COFF groups are disabled for MINGW because it significantly increases PDB sizes. We could enable that later with an option. The overall objective for this change is to support code hot patching tools. Such tools need to know the import libraries used, from the PDB alone. Differential Revision: https://reviews.llvm.org/D54802 llvm-svn: 357308
* [LLD][COFF] Add support for /FUNCTIONPADMIN command-line optionAlexandre Ganea2019-02-231-0/+58
| | | | | | | | | | Initial patch by Stefan Reinalter. Fixes PR36775 Differential Revision: https://reviews.llvm.org/D49366 llvm-svn: 354716
* [lld-link] preserve @llvm.used symbols in LTOBob Haarman2019-02-201-0/+2
| | | | | | | | | | | | | | | | | | | | | | | Summary: We translate @llvm.used to COFF by generating /include directives in the .drectve section. However, in LTO links, this happens after directives have already been processed, so the new directives do not take effect. This change marks @llvm.used symbols as GCRoots so that they are preserved as intended. Fixes PR40733. Reviewers: rnk, pcc, ruiu Reviewed By: ruiu Subscribers: mehdi_amini, steven_wu, dexonsmith, dang, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D58255 llvm-svn: 354410
* lld/coff: Simplify error message for comdat selection mismatchesNico Weber2019-02-141-98/+103
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | Turns out nobody understands what "conflicting comdat type" is supposed to mean, so just emit a regular "duplicate symbol" error and move the comdat selection information into /verbose output. This also fixes a problem where the error output would depend on the order of .obj files passed. Before this patch: - If passed `one_only.obj discard.obj`, lld-link would only err "conflicting comdat type" - If passed `discard.obj one_only.obj`, lld-link would err "conflicting comdat type" and then "duplicate symbol" Now lld-link only errs "duplicate symbol" in both cases. I considered adding a "Detail" parameter to reportDuplicate() that's printed in parens at the end of the "duplicate symbol" diag if present, and then put the comdat selection mismatch details there, but since users don't know what it's supposed to mean decided against it. I also considered special-casing the Detail message for one_only/discard mismatches, which in practice means "function defined as inline in TU 1 but as out-of-line in TU 2", but I wasn't sure how useful it is so I omitted that too. Differential Revision: https://reviews.llvm.org/D58180 llvm-svn: 354006
* 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
* lld/coff: Implement some support for the comdat selection fieldNico Weber2019-01-301-11/+126
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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-link: Store comdat selection in SectionChunk, reject more invalid ↵Nico Weber2019-01-261-5/+16
| | | | | | | | | | | | | | 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
* 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
* 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-7/+10
| | | | | | | | | | | | | | 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] Fix error handling on duplicates for import library symbolsMartin Storsjo2018-10-191-0/+4
| | | | | | | | | Normally one wouldn't run into that case, but it is possible with a little creative ordering of special libraries. Differential Revision: https://reviews.llvm.org/D53388 llvm-svn: 344776
* [COFF] Cope with GCC produced weak aliases referring to comdat functionsMartin Storsjo2018-10-051-0/+7
| | | | | | | | | | | | For certain cases of inline functions written to comdat sections, GCC 5.x produces a weak symbol in addition, which would end up undefined in some cases. This no longer seems to happen with GCC 6.x or newer though. Differential Revision: https://reviews.llvm.org/D52602 llvm-svn: 343877
* [COFF] Cope with weak aliases produced by GNU toolsMartin Storsjo2018-10-031-1/+9
| | | | | | | | | | | | | | | When GNU tools create a weak alias, they produce a strong symbol named .weak.<weaksymbol>.<relatedstrongsymbol>. GNU ld allows many such weak alternatives for the same weak symbol, and the linker picks the first one encountered. This can't be reproduced by assembling from .s files, since llvm-mc produces symbols named .weak.<weaksymbol>.default in these cases. Differential Revision: https://reviews.llvm.org/D52601 llvm-svn: 343704
* COFF: Implement safe ICF on rodata using address-significance tables.Peter Collingbourne2018-08-231-0/+5
| | | | | | Differential Revision: https://reviews.llvm.org/D51050 llvm-svn: 340555
* [COFF] Treat .xdata/.pdata$<sym> as implicitly associative to <sym> for MinGWMartin Storsjo2018-08-061-5/+49
| | | | | | | | | | | | | | | | | | | MinGW configurations don't use associative comdats, as GNU ld doesn't support that. Instead they produce normal comdats named .text$sym, .xdata$sym and .pdata$sym. GNU ld doesn't discard any comdats starting with .xdata or .pdata, even if --gc-sections is used (while it does discard other unreferenced comdats), regardless of what symbol name is used after the $ separator. For LLD, treat any such comdat as implicitly associative to the base symbol. This requires maintaining a map from symbol name to section number, but that is only maintained when the MinGW flag has been enabled. Differential Revision: https://reviews.llvm.org/D49700 llvm-svn: 339058
* [COFF] Handle comdat sections without leader symbolsMartin Storsjo2018-07-261-0/+7
| | | | | | | | | | | | | | | | | Discard them unless they have been associated by other means (yet uimplemented). According to MS link.exe, such sections are illegal, but MinGW setups use them in their take on associative comdats. This avoids leaving references to the bogus SectionChunk* PendingComdat, which cannot be dereferenced. This fixes PR38183. Differential Revision: https://reviews.llvm.org/D49653 llvm-svn: 338064
* Fix error messages for bad symbols.Rui Ueyama2018-07-241-13/+19
| | | | | | | | | Previously, the error messages didn't contain symbol name because we didn't read a symbol name for these error messages. Differential Revision: https://reviews.llvm.org/D49762 llvm-svn: 337863
* Simplify; no behavior change.Nico Weber2018-07-201-4/+2
| | | | | | Reviewed as part of https://reviews.llvm.org/D49189 llvm-svn: 337633
OpenPOWER on IntegriCloud