summaryrefslogtreecommitdiffstats
path: root/lld/COFF
Commit message (Collapse)AuthorAgeFilesLines
...
* [lld-link] Generalize handling of /debug and ↵Will Wilson2018-09-242-29/+67
| | | | | | | | | | | | | /debug:{none,full,fastlink,ghash,symtab} Implement final argument precedence if multiple /debug arguments are passed on the command-line to match expected link.exe behavior. Support /debug:none and emit warning for /debug:fastlink with automatic fallback to /debug:full. Emit error if last /debug:option is unknown. Emit warning if last /debugtype:option is unknown. https://reviews.llvm.org/D50404 llvm-svn: 342894
* [COFF] Support linking to import libraries from GNU binutilsMartin Storsjo2018-09-213-52/+151
| | | | | | | | | | | | | | | | | | | | | | | | GNU binutils import libraries aren't the same kind of short import libraries as link.exe and LLD produce, but are a plain static library containing .idata section chunks. MSVC link.exe can successfully link to them. In order for imports from GNU import libraries to mix properly with the normal import chunks, the chunks from the existing mechanism needs to be added into named sections like .idata$2. These GNU import libraries consist of one header object, a number of object files, one for each imported function/variable, and one trailer. Within the import libraries, the object files are ordered alphabetically in this order. The chunks stemming from these libraries have to be grouped by what library they originate from and sorted, to make sure the section chunks for headers and trailers for the lists are ordered as intended. This is done on all sections named .idata$*, before adding the synthesized chunks to them. Differential Revision: https://reviews.llvm.org/D38513 llvm-svn: 342777
* [COFF] Fix the name mangling of a function in the autoexport exclusion listMartin Storsjo2018-09-181-1/+1
| | | | | | | The __NULL_IMPORT_DESCRIPTOR symbol has two leading underscores on architectures other than i386 as well; it is not a mangled symbol name. llvm-svn: 342448
* [COFF] Add support for delay loading DLLs for ARM64Martin Storsjo2018-09-183-3/+61
| | | | | | Differential Revision: https://reviews.llvm.org/D52190 llvm-svn: 342447
* [COFF] Fix a block with incorrect indentation. NFC.Martin Storsjo2018-09-181-3/+3
| | | | llvm-svn: 342446
* lld-link: Set PDB GUID to hash of PDB contents instead of to a random byte ↵Nico Weber2018-09-153-100/+24
| | | | | | | | | | | | | | | | | | | | | | | sequence. Previously, lld-link would use a random byte sequence as the PDB GUID. Instead, use a hash of the PDB file contents. To not disturb llvm-pdbutil pdb2yaml, the hash generation is an opt-in feature on InfoStreamBuilder and ldb/COFF/PDB.cpp always sets it. Since writing the PDB computes this ID which also goes in the exe, the PDB writing code now must be called before writeBuildId(). writeBuildId() for that reason is no longer included in the "Code Layout" timer. Since the PDB GUID is now a function of the PDB contents, the PDB Age is always set to 1. There was a long comment above loadExistingBuildId (now gone) about how not changing the GUID and only incrementing the age was important, but according to the discussion in PR35914 that comment was incorrect. Differential Revision: https://reviews.llvm.org/D51956 llvm-svn: 342334
* lld-link: print demangled symbol names for "undefined symbol" diagnosticsNico Weber2018-09-151-19/+17
| | | | | | | | | | | | | | | | | For this, add a few toString() calls when printing the "undefined symbol" diagnostics; toString() already does demangling on Windows hosts. Also make lld::demangleMSVC() (called by toString(Symbol*)) call LLVM's microsoftDemangle() instead of UnDecorateSymbolName() so that it works on non-Windows hosts – this makes both updating tests easier and provides a better user experience for people doing cross-links. This doesn't yet do the right thing for symbols starting with __imp_, but that can be improved in a follow-up. Differential Revision: https://reviews.llvm.org/D52104 llvm-svn: 342332
* [COFF] Provide __CTOR_LIST__ and __DTOR_LIST__ symbols for MinGWMartin Storsjo2018-09-145-1/+66
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | MinGW uses these kind of list terminator symbols for traversing the constructor/destructor lists. These list terminators are actual pointers entries in the lists, with the values 0 and (uintptr_t)-1 (instead of just symbols pointing to the start/end of the list). (This mechanism exists in both the mingw-w64 crt startup code and in libgcc; normally the mingw-w64 one is used, but a DLL build of libgcc uses the libgcc one. Therefore it's not trivial to change the mechanism without lots of cross-project synchronization and potentially invalidating some combinations of old/new versions of them.) When mingw-w64 has been used with lld so far, the CRT startup object files have so far provided these symbols, ending up with different, incompatible builds of the CRT startup object files depending on whether binutils or lld are going to be used. In order to avoid the need of different configuration of the CRT startup object files depending on what linker to be used, provide these symbols in lld instead. (Mingw-w64 checks at build time whether the linker provides these symbols or not.) This unifies this particular detail between the two linkers. This does disallow the use of the very latest lld with older versions of mingw-w64 (the configure check for the list was added recently; earlier it simply checked whether the CRT was built with gcc or clang), and requires rebuilding the mingw-w64 CRT. But the number of users of lld+mingw still is low enough that such a change should be tolerable, and unifies this aspect of the toolchains, easing interoperability between the toolchains for the future. The actual test for this feature is added in ctors_dtors_priority.s, but a number of other tests that checked absolute output addresses are updated. Differential Revision: https://reviews.llvm.org/D52053 llvm-svn: 342294
* [COFF] Avoid copying of chunk vectors. NFC.Martin Storsjo2018-09-141-1/+1
| | | | | | | | | | | | When declaring the pair variable as "auto Pair : Map", it is effectively declared as std::pair<std::pair<StringRef, uint32_t>, std::vector<Chunk *>>. This effectively does a full, shallow copy of the Chunk vector, just to be thrown away after each iteration. Differential Revision: https://reviews.llvm.org/D52051 llvm-svn: 342205
* COFF: Add support for /force:multiple optionRui Ueyama2018-09-134-7/+21
| | | | | | | | | | | Patch by Thomas Roughton. This patch adds support for linking with multiple definitions to LLD's COFF driver, in line with link.exe's /force:multiple option. Differential Revision: https://reviews.llvm.org/D50598 llvm-svn: 342191
* lld-link: For nonexisting inputs, omit follow-on diagnosticsNico Weber2018-09-131-0/+3
| | | | | | | | | | | | | | | | For lld-link missing.obj, lld-link currently prints: lld-link: error: could not open foo.obj: No such file or directory lld-link: warning: /machine is not specified. x64 is assumed lld-link: error: subsystem must be defined The 2nd and 3rd diagnostics are consequences of the input not existing and are not interesting. If input files are missing, the best thing we can do is point that out and then return. Differential Revision: https://reviews.llvm.org/D51981 llvm-svn: 342158
* [PDB] Emit old fpo data to the PDB file.Zachary Turner2018-09-121-110/+181
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | r342003 added support for emitting FPO data from the DEBUG_S_FRAMEDATA subsection of the .debug$S section to the PDB file. However, that is not the end of the story. FPO can end up in two different destinations in a PDB, each corresponding to a different FPO data source. The case handled by r342003 involves copying data from the DEBUG_S_FRAMEDATA subsection of the .debug$S section to the "New FPO" stream in the PDB, which is then referred to by the DBI stream. The case handled by this patch involves copying records from the .debug$F section of an object file to the "FPO" stream (or perhaps more aptly, the "Old FPO" stream) in the PDB file, which is also referred to by the DBI stream. The formats are largely similar, and the difference is mostly only visible in masm generated object files, such as some of the low-level CRT object files like memcpy. MASM doesn't appear to support writing the DEBUG_S_FRAMEDATA subsection, and instead just writes these records to the .debug$F section. Although clang-cl does not emit a .debug$F section ever, lld still needs to support it so we have good debugging for CRT functions. Differential Revision: https://reviews.llvm.org/D51958 llvm-svn: 342080
* [PDB] Write FPO Data to the PDB.Zachary Turner2018-09-111-11/+39
| | | | llvm-svn: 342003
* Buildfix for r341825Alexandre Ganea2018-09-101-3/+3
| | | | llvm-svn: 341827
* [LLD][COFF] Cleanup error messages / add more coverage testsAlexandre Ganea2018-09-101-21/+41
| | | | | | | | | | | | - Log the reason for a PDB or precompiled-OBJ load failure - Properly handle out-of-date PDB or precompiled-OBJ signature by displaying a corresponding error - Slightly change behavior on PDB failure: any subsequent load attempt from another OBJ would result in the same error message being logged - Slightly change behavior on PDB failure: retry with filename only if previous error was ENOENT ("no such file or directory") - Tests: a. for native PDB errors; b. cover all the cases above Differential Revision: https://reviews.llvm.org/D51559 llvm-svn: 341825
* Remove an effectively unused local variable.Nico Weber2018-09-101-3/+2
| | | | llvm-svn: 341823
* [COFF] don't mark lazy symbols as used in regular objectsBob Haarman2018-09-062-4/+12
| | | | | | | | | | | | | | | | | | Summary: r338767 updated the COFF and wasm linker SymbolTable code to be strutured more like the ELF linker's. That inadvertedly changed the behavior of the COFF linker so that lazy symbols would be marked as used in regular objects. This change adds an overload of the insert() function, similar to the ELF linker, which does not perform that marking. Reviewers: ruiu, rnk, hans Subscribers: aheejin, sunfish, llvm-commits Differential Revision: https://reviews.llvm.org/D51720 llvm-svn: 341585
* lld-link: Write an empty "repro" debug directory entry if /Brepro is passedNico Weber2018-09-051-18/+36
| | | | | | | | | | | If the coff timestamp is set to a hash, like lld-link does if /Brepro is passed, the coff spec suggests that a IMAGE_DEBUG_TYPE_REPRO entry is in the debug directory. This lets lld-link write such a section. Fixes PR38429, see bug for details. Differential Revision: https://reviews.llvm.org/D51652 llvm-svn: 341486
* [COFF] Allow exporting all symbols from system libraries specfied with ↵Martin Storsjo2018-09-043-4/+21
| | | | | | | | | | | | | | | -wholearchive: When building a shared libc++.dll, it pulls in libc++abi.a statically with the --wholearchive flag. If such a build is done with --export-all-symbols, it's reasonable to assume that everything from that library also should be exported with the same rules as normal local object files, even though we normally avoid autoexporting things from libc++abi.a in other cases when linking a DLL (user code). Differential Revision: https://reviews.llvm.org/D51529 llvm-svn: 341403
* [DebugInfo] Common behavior for error typesAlexandre Ganea2018-08-311-4/+4
| | | | | | | | | | | | | | | Following D50807, and heading towards D50664, this intermediary change does the following: 1. Upgrade all custom Error types in llvm/trunk/lib/DebugInfo/ to use the new StringError behavior (D50807). 2. Implement std::is_error_code_enum and make_error_code() for DebugInfo error enumerations. 3. Rename GenericError -> PDBError (the file will be renamed in a subsequent commit) 4. Update custom error messages to follow the same formatting: (\w\s*)+\. 5. Keep generic "file not found" (ENOENT) errors as they are in PDB code. Previously, there used to be a custom enumeration for that purpose. 6. Remove a few extraneous LF in log() implementations. Printing LF is a responsability at a higher level, not at the error level. Differential Revision: https://reviews.llvm.org/D51499 llvm-svn: 341228
* [COFF] When doing automatic dll imports, replace whole .refptr.<var> chunks ↵Martin Storsjo2018-08-318-27/+34
| | | | | | | | | | | | | | | | | | | | with __imp_<var> After fixing up the runtime pseudo relocation, the .refptr.<var> will be a plain pointer with the same value as the IAT entry itself. To save a little binary size and reduce the number of runtime pseudo relocations, redirect references to the IAT entry (via the __imp_<var> symbol) itself and discard the .refptr.<var> chunk (as long as the same section chunk doesn't contain anything else than the single pointer). As there are now cases for both setting the Live variable to true and false externally, remove the accessors and setters and just make the variable public instead. Differential Revision: https://reviews.llvm.org/D51456 llvm-svn: 341175
* [COFF] Skip exporting artificial symbols when exporting all symbolsMartin Storsjo2018-08-301-2/+3
| | | | | | Differential Revision: https://reviews.llvm.org/D51457 llvm-svn: 341017
* [COFF] Merge the .ctors, .dtors and .CRT sections into .rdata for MinGWMartin Storsjo2018-08-291-0/+6
| | | | | | | | | | | | | | | | | There's no point in keeping them as separate sections. This differs from GNU ld, which places .ctors and .dtors content in .text (implemented by a built-in linker script). But since the content only is pointers, there's no need to have it executable. GNU ld also leaves .CRT separate as its own standalone section. MSVC merges .CRT into .rdata similarly, with a directive embedded in an object file in msvcrt.lib or libcmt.lib. Differential Revision: https://reviews.llvm.org/D51414 llvm-svn: 340940
* fix comment typoNico Weber2018-08-271-1/+1
| | | | llvm-svn: 340742
* [COFF] Support MinGW automatic dllimport of dataMartin Storsjo2018-08-278-0/+301
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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
* Rename a function to follow the LLVM coding style.Rui Ueyama2018-08-271-1/+1
| | | | llvm-svn: 340716
* [COFF] Check the instructions in ARM MOV32T relocationsMartin Storsjo2018-08-271-3/+9
| | | | | | | | | | For this relocation, which applies to two consecutive instructions, it's plausible that the second instruction might not actually be the right one. Differential Revision: https://reviews.llvm.org/D50998 llvm-svn: 340715
* COFF: Implement safe ICF on rodata using address-significance tables.Peter Collingbourne2018-08-235-2/+60
| | | | | | Differential Revision: https://reviews.llvm.org/D51050 llvm-svn: 340555
* win: Omit ".exe" from lld warning and error messages.Nico Weber2018-08-221-1/+1
| | | | | | | | | | | This is a minor follow-up to https://reviews.llvm.org/D49189. On Windows, lld used to print "lld-link.exe: error: ...". Now it just prints "lld-link: error: ...". This matches what link.exe does (it prints "LINK : ...") and makes lld's output less dependent on the host system. https://reviews.llvm.org/D51133 llvm-svn: 340487
* lld-link: Separate 'undefined symbol' errors with just one newline, not two.Nico Weber2018-08-221-2/+1
| | | | | | | | | | | | | newline() in ErrorHandler.cpp already tries to insert newlines between messages that contain embedded newlines, so getSymbolLocations() shouldn't return a string that ends in a newline -- else we end up with two newlines between error messages. Makes lld-link's output look more like ld.lld output. https://reviews.llvm.org/D51117 llvm-svn: 340482
* lld-link: Emit warning if one each of {main,wmain} and {WinMain,wWinMain} ↵Nico Weber2018-08-221-2/+12
| | | | | | | | | exist and no /subsystem: flag is passed. Similar to link.exe's LNK4031. https://reviews.llvm.org/D51076 llvm-svn: 340420
* [COFF] Move a comment close to the code it refers to. NFC.Martin Storsjo2018-08-221-3/+3
| | | | llvm-svn: 340400
* [COFF] Change fatal() into error() when writing chunks to the outputMartin Storsjo2018-08-221-15/+20
| | | | | | | | | | In most of these cases, it's easy to go on despite the error, printing as many valuable error messages as possible from one run as possible. Differential Revision: https://reviews.llvm.org/D51087 llvm-svn: 340399
* [COFF] Make the relocation scanning for CFG more discriminatingHans Wennborg2018-08-091-7/+13
| | | | | | | | | link.exe ignores REL32 relocations on 32-bit x86, as well as relocations against non-function symbols such as labels. This makes lld do the same. Differential Revision: https://reviews.llvm.org/D50430 llvm-svn: 339345
* lld-link: Take /SUBSYSTEM into account for automatic /ENTRY detection.Nico Weber2018-08-071-40/+44
| | | | | | | | | | | | | | | | | | | | | | | | | | | | If /subsystem:windows is passed, link.exe only looks for WinMain and wWinMain, and if /subsystem:console is passed it only looks for main and wmain. lld-link used to look for all 4 in both cases. This patch makes lld-link match link.exe's behavior. This requires that the subsystem is known by the time findDefaultEntry() gets called. findDefaultEntry() is called before the main link loop, so that the loop can mark the entry point as undefined. That means inferSubsystem() has to be called above the main loop as well. This in turn means /subsystem: from .drectve sections only has an effect on entry point inference for obj files passed to lld-link directly (and not in obj files found later in .lib files). link.exe seems to ignore /subsystem: for obj files from lib files completely (while in lld it's ignored only for entry point detection but it still overrides /subsystem: flags passed on the command line for the value that gets written in the output file). Also, if the subsytem isn't needed (e.g. when only writing a /def: lib file and not writing a coff file), link.exe doesn't complain if the subsystem isn't known, so both subsystem and entry point handling should be below the early return lld has for that case. Fixes PR36523. https://reviews.llvm.org/D50316 llvm-svn: 339165
* [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
* [COFF] Treat .xdata/.pdata$<sym> as implicitly associative to <sym> for MinGWMartin Storsjo2018-08-062-6/+65
| | | | | | | | | | | | | | | | | | | 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] Remove a superfluous warning about aligncomm for non-common symbolsMartin Storsjo2018-08-061-3/+3
| | | | | | | | | | | It's not an error if a common symbol (uninitialized data, with alignment specified via the aligncomm directive) is replaced with a regular one with initialized data (with alignment specified via the section chunk). Differential Revision: https://reviews.llvm.org/D50268 llvm-svn: 339049
* lld-link: Simplify LinkerDriver::findDefaultEntry()Nico Weber2018-08-031-13/+4
| | | | | | | | | No intended behavior change. Not repeating the CRTStartup names makes fixing PR36523 simpler. https://reviews.llvm.org/D50253 llvm-svn: 338911
* lld-link: Fix subsystem inference for non-console apps on 32-bit, and fix ↵Nico Weber2018-08-032-15/+17
| | | | | | | | | | | | | | | | | | | | | | | entry point inference on 32-bit with /nodefaultlib LinkerDriver::inferSubsystem() used to do Symtab->findUnderscore("WinMain"), but WinMain is stdcall in 32-bit and is hence is called _WinMain@16. Instead, Symtab->findMangle(mangle("WinMain")) needs to be called. But since LinkerDriver::inferSubsystem() and LinkerDriver::findDefaultEntry() both need to call this, introduce a common helper function for this and call it from both places. (Also call it for "main" for consistency, even though findUnderscore() is enough for main since that's __cdecl on 32-bit). This also exposed a bug for /nodefaultlib entrypoint inference: The code here called findMangle(Sym) instead of findMangle(mangle(Sym)), again doing the wrong thing on 32-bit. Fix that too. While here, make Driver::mangle() a static free function. https://reviews.llvm.org/D50184 llvm-svn: 338877
* Set IsUsedInRegularObj in a consistent manor between COFF, ELF and wasm. NFCSam Clegg2018-08-022-26/+22
| | | | | | Differential Revision: https://reviews.llvm.org/D49147 llvm-svn: 338767
* lld-link: Remove /msvclto optionNico Weber2018-08-014-155/+0
| | | | | | | | | | | This was useful for LTO bringup in lld-link while lld couldn't write PDBs. Now that it can, this should no longer be needed. Hopefully the flag is obscure enough and recent enough, that nobody uses it – but if somebody should use it, they should be able to just stop passing it and things should continue to work. https://reviews.llvm.org/D50139 llvm-svn: 338615
* Make ICF log output order deterministic.Rui Ueyama2018-07-311-8/+2
| | | | | | | | | | This patch does the same thing as r338153 for COFF. Note that this patch affects only the order of log messages. The output file is already deterministic. Differential Revision: https://reviews.llvm.org/D50023 llvm-svn: 338406
* [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
* [COFF] clean up global resources after completionRui Ueyama2018-07-261-0/+3
| | | | | | | | | | | | | Patch by Andrew Kelley. Previously, running lld::coff::link() twice in the same process would access stale pointers because of these global variables not being reset. After this patch, lld::coff::link() can be called any number of times, just like its ELF and MACH-O counterparts. Differential Revision: https://reviews.llvm.org/D49856 llvm-svn: 338042
* 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
* Omit path to lld binary from lld's error, warning, and log output.Nico Weber2018-07-201-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | lld currently prepends the absolute path to itself to every diagnostic it emits. This path can be longer than the diagnostic, and makes the actual error message hard to read. There isn't a good reason for printing this path: if you want to know which lld you're running, pass -v to clang – chances are that if you're unsure of this, you're not only unsure when it errors out. Some people want an indication that the diagnostic is from the linker though, so instead print just the basename of the linker's path. Before: ``` $ out/bin/clang -target x86_64-unknown-linux -x c++ /dev/null -fuse-ld=lld /Users/thakis/src/llvm-mono/out/bin/ld.lld: error: cannot open crt1.o: No such file or directory /Users/thakis/src/llvm-mono/out/bin/ld.lld: error: cannot open crti.o: No such file or directory /Users/thakis/src/llvm-mono/out/bin/ld.lld: error: cannot open crtbegin.o: No such file or directory /Users/thakis/src/llvm-mono/out/bin/ld.lld: error: unable to find library -lgcc /Users/thakis/src/llvm-mono/out/bin/ld.lld: error: unable to find library -lgcc_s /Users/thakis/src/llvm-mono/out/bin/ld.lld: error: unable to find library -lc /Users/thakis/src/llvm-mono/out/bin/ld.lld: error: unable to find library -lgcc /Users/thakis/src/llvm-mono/out/bin/ld.lld: error: unable to find library -lgcc_s /Users/thakis/src/llvm-mono/out/bin/ld.lld: error: cannot open crtend.o: No such file or directory /Users/thakis/src/llvm-mono/out/bin/ld.lld: error: cannot open crtn.o: No such file or directory clang: error: linker command failed with exit code 1 (use -v to see invocation) ``` After: ``` $ out/bin/clang -target x86_64-unknown-linux -x c++ /dev/null -fuse-ld=lld ld.lld: error: cannot open crt1.o: No such file or directory ld.lld: error: cannot open crti.o: No such file or directory ld.lld: error: cannot open crtbegin.o: No such file or directory ld.lld: error: unable to find library -lgcc ld.lld: error: unable to find library -lgcc_s ld.lld: error: unable to find library -lc ld.lld: error: unable to find library -lgcc ld.lld: error: unable to find library -lgcc_s ld.lld: error: cannot open crtend.o: No such file or directory ld.lld: error: cannot open crtn.o: No such file or directory clang: error: linker command failed with exit code 1 (use -v to see invocation) ``` https://reviews.llvm.org/D49189 llvm-svn: 337634
* Simplify; no behavior change.Nico Weber2018-07-201-4/+2
| | | | | | Reviewed as part of https://reviews.llvm.org/D49189 llvm-svn: 337633
* [PDB] Write the command line after response file expansionReid Kleckner2018-07-202-10/+14
| | | | | | | | | | | | Summary: Fixes PR38085 Reviewers: ruiu, zturner Subscribers: llvm-commits Differential Revision: https://reviews.llvm.org/D49566 llvm-svn: 337628
* [COFF] Sort .reloc before all other discardable sectionsMartin Storsjo2018-07-201-5/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | If a binary is stripped, which can remove discardable sections (except for the .reloc section, which also is marked as discardable as it isn't loaded at runtime, only read by the loader), the .reloc section should be first of them, in order not to create gaps in the image. Previously, binaries with relocations were broken if they were stripped by GNU binutils strip. Trying to execute such binaries produces an error about "xx is not a valid win32 application". This fixes GNU binutils bug 23348. Prior to SVN r329370 (which didn't intend to have functional changes), the code for moving discardable sections to the end didn't clearly express how other discardable sections should be ordered compared to .reloc, but the change retained the exact same end result as before. After SVN r329370, the code (and comments) more clearly indicate that it tries to make the .reloc section the absolutely last one; this patch changes that. This matches how GNU binutils ld sorts .reloc compared to dwarf debug info sections. Differential Revision: https://reviews.llvm.org/D49351 Signed-off-by: Martin Storsjö <martin@martin.st> llvm-svn: 337598
OpenPOWER on IntegriCloud