| 文件 | 最后提交记录 | 最后更新时间 |
|---|---|---|
[PDB] Fix bug when using multiple PCH header objects with the same name. A common pattern in Windows is to have all your precompiled headers use an object named stdafx.obj. If you've got a project with many different static libs, you might use a separate PCH for each one of these. During the final link step, a file from A might reference the PCH object from A, but it will have the same name (stdafx.obj) as any other PCH from another project. The only difference will be the path. For example, A might be A/stdafx.obj while B is B/stdafx.obj. The existing algorithm checks only the filename that was passed on the command line (or stored in archive), but this is insufficient in the case where relative paths are used, because depending on the command line object file / library order, it might find the wrong PCH object first resulting in a signature mismatch. The fix here is to simply check whether the absolute path of the PCH object (which is stored in the input obj file for the file that references the PCH) *ends with* the full relative path of whatever is specified on the command line (or is in the archive). Differential Revision: https://reviews.llvm.org/D66431 llvm-svn: 374442 | 6 年前 | |
[PDB] Fix bug when using multiple PCH header objects with the same name. A common pattern in Windows is to have all your precompiled headers use an object named stdafx.obj. If you've got a project with many different static libs, you might use a separate PCH for each one of these. During the final link step, a file from A might reference the PCH object from A, but it will have the same name (stdafx.obj) as any other PCH from another project. The only difference will be the path. For example, A might be A/stdafx.obj while B is B/stdafx.obj. The existing algorithm checks only the filename that was passed on the command line (or stored in archive), but this is insufficient in the case where relative paths are used, because depending on the command line object file / library order, it might find the wrong PCH object first resulting in a signature mismatch. The fix here is to simply check whether the absolute path of the PCH object (which is stored in the input obj file for the file that references the PCH) *ends with* the full relative path of whatever is specified on the command line (or is in the archive). Differential Revision: https://reviews.llvm.org/D66431 llvm-svn: 374442 | 6 年前 | |
[COFF] Avoid loading objects for mingw autoimport, when a defined alias exists This avoids a spurious and confusing log message in cases where both e.g. "alias" and "__imp_alias" exist. Differential Revision: https://reviews.llvm.org/D65598 llvm-svn: 367673 | 6 年前 | |
COFF: handle multiply defined symbols with different storage If a symbol is locally defined and is DLL imported in another translation unit, and the object with the locally defined version is loaded prior to the imported version, then the linker will fail to resolve the definition of the thunk and return the locally defined symbol. This will then be attempted to be cast to an import thunk, which will clearly fail. Only return the thunk if the symbol is inserted or a thunk is created. Otherwise, report a duplication error. llvm-svn: 312386 | 8 年前 | |
[yaml2obj] Updating LLD tests to account for LLVM r273915 This removed the -format flag from yaml2obj in favor of YAML tags. llvm-svn: 273920 | 9 年前 | |
COFF: ARM: Set correct entry point address. llvm-svn: 243199 | 10 年前 | |
[COFF] Drop unused comdat sections when GC is turned off Summary: Adds a "Discarded" bool to SectionChunk to indicate if the section was discarded by COMDAT deduplication. The Writer still just checks isLive(). Fixes PR33446 Reviewers: ruiu Subscribers: llvm-commits Differential Revision: https://reviews.llvm.org/D34288 llvm-svn: 305582 | 8 年前 | |
[COFF] Treat .xdata/.pdata$<sym> as implicitly associative to <sym> for MinGW 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 | 7 年前 | |
[LLD][COFF] Cleanup error messages / add more coverage tests - 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 | 7 年前 | |
Reland "Change the X86 datalayout to add three address spaces for 32 bit signed, 32 bit unsigned, and 64 bit pointers." This reverts 57076d3199fc2b0af4a3736b7749dd5462cacda5. Original review at https://reviews.llvm.org/D64931. Review for added fix at https://reviews.llvm.org/D66843. llvm-svn: 371568 | 6 年前 | |
COFF: handle multiply defined symbols with different storage If a symbol is locally defined and is DLL imported in another translation unit, and the object with the locally defined version is loaded prior to the imported version, then the linker will fail to resolve the definition of the thunk and return the locally defined symbol. This will then be attempted to be cast to an import thunk, which will clearly fail. Only return the thunk if the symbol is inserted or a thunk is created. Otherwise, report a duplication error. llvm-svn: 312386 | 8 年前 | |
Partially revert r287009: Remove trailing whitespace. This reverts part of r287009 because I accidentally changed binary files. llvm-svn: 287010 | 9 年前 | |
Delete trailing \r. NFC llvm-svn: 359745 | 7 年前 | |
Add more stringent tests for the resource section of executables. Summary: The testing on the resource section of executables produced by lld has been very lax, and allowed a major bug to go unnoticed when we switched from shelling out to cvtres.exe to using llvm's own library. These additional tests should cover all the major failure points. Reviewers: zturner, ruiu Subscribers: llvm-commits Differential Revision: https://reviews.llvm.org/D34664 llvm-svn: 306465 | 8 年前 | |
[LLD] [COFF] Support merging resource object files 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 | 6 年前 | |
Add more stringent tests for the resource section of executables. Summary: The testing on the resource section of executables produced by lld has been very lax, and allowed a major bug to go unnoticed when we switched from shelling out to cvtres.exe to using llvm's own library. These additional tests should cover all the major failure points. Reviewers: zturner, ruiu Subscribers: llvm-commits Differential Revision: https://reviews.llvm.org/D34664 llvm-svn: 306465 | 8 年前 | |
Add more stringent tests for the resource section of executables. Summary: The testing on the resource section of executables produced by lld has been very lax, and allowed a major bug to go unnoticed when we switched from shelling out to cvtres.exe to using llvm's own library. These additional tests should cover all the major failure points. Reviewers: zturner, ruiu Subscribers: llvm-commits Differential Revision: https://reviews.llvm.org/D34664 llvm-svn: 306465 | 8 年前 | |
Add more stringent tests for the resource section of executables. Summary: The testing on the resource section of executables produced by lld has been very lax, and allowed a major bug to go unnoticed when we switched from shelling out to cvtres.exe to using llvm's own library. These additional tests should cover all the major failure points. Reviewers: zturner, ruiu Subscribers: llvm-commits Differential Revision: https://reviews.llvm.org/D34664 llvm-svn: 306465 | 8 年前 | |
Add more stringent tests for the resource section of executables. Summary: The testing on the resource section of executables produced by lld has been very lax, and allowed a major bug to go unnoticed when we switched from shelling out to cvtres.exe to using llvm's own library. These additional tests should cover all the major failure points. Reviewers: zturner, ruiu Subscribers: llvm-commits Differential Revision: https://reviews.llvm.org/D34664 llvm-svn: 306465 | 8 年前 | |
[LLD] [COFF] Support merging resource object files 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 | 6 年前 | |
[LLD] [COFF] Check the aux section definition size for IMAGE_COMDAT_SELECT_SAME_SIZE Binutils generated sections seem to be padded to a multiple of 16 bytes, but the aux section definition contains the original, unpadded section length. The size check used for IMAGE_COMDAT_SELECT_SAME_SIZE previously only checked the size of the section itself. When checking the currently processed object file against the previously chosen comdat section, we easily have access to the aux section definition of the currently processed section, but we have to iterate over the symbols of the previously selected object file to find the section definition of the previously picked section. (We don't want to inflate SectionChunk to carry more data, for something that is only needed in corner cases.) Only do this when the mingw flag is set. This fixes statically linking clang-built C++ object files against libstdc++ built with GCC, if the object files contain e.g. typeinfo. Differential Revision: https://reviews.llvm.org/D86659 | 5 年前 | |
[COFF] In MinGW mode, ignore relocations against a discarded section When GCC produces a jump table as part of a comdat function, the jump table itself is produced as plain non-comdat rdata section. When linked with ld.bfd, all of those rdata sections are kept, with relocations unchanged in the sections that refer to discarded comdat sections. This has been observed with at least GCC 5.x and 7.x. Differential Revision: https://reviews.llvm.org/D52600 llvm-svn: 343422 | 7 年前 | |
[LLD] [COFF] Check the aux section definition size for IMAGE_COMDAT_SELECT_SAME_SIZE Binutils generated sections seem to be padded to a multiple of 16 bytes, but the aux section definition contains the original, unpadded section length. The size check used for IMAGE_COMDAT_SELECT_SAME_SIZE previously only checked the size of the section itself. When checking the currently processed object file against the previously chosen comdat section, we easily have access to the aux section definition of the currently processed section, but we have to iterate over the symbols of the previously selected object file to find the section definition of the previously picked section. (We don't want to inflate SectionChunk to carry more data, for something that is only needed in corner cases.) Only do this when the mingw flag is set. This fixes statically linking clang-built C++ object files against libstdc++ built with GCC, if the object files contain e.g. typeinfo. Differential Revision: https://reviews.llvm.org/D86659 | 5 年前 | |
[COFF] Remove a superfluous warning about aligncomm for non-common symbols 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 | 7 年前 | |
Reland "Change the X86 datalayout to add three address spaces for 32 bit signed, 32 bit unsigned, and 64 bit pointers." This reverts 57076d3199fc2b0af4a3736b7749dd5462cacda5. Original review at https://reviews.llvm.org/D64931. Review for added fix at https://reviews.llvm.org/D66843. llvm-svn: 371568 | 6 年前 | |
Reland "Change the X86 datalayout to add three address spaces for 32 bit signed, 32 bit unsigned, and 64 bit pointers." This reverts 57076d3199fc2b0af4a3736b7749dd5462cacda5. Original review at https://reviews.llvm.org/D64931. Review for added fix at https://reviews.llvm.org/D66843. llvm-svn: 371568 | 6 年前 | |
COFF: actually synthesize CONST imports properly CONSTANT imports expect both the _imp_ prefixed and non-prefixed symbols should be added to the symbol table. This allows for linking symbols like _NSConcreteGlobalBlock in WinObjC. The previous change would generate the import library properly by handling the option but would not consume the generated entry properly. llvm-svn: 301657 | 9 年前 | |
Delete trailing \r. NFC llvm-svn: 359745 | 7 年前 | |
Delete trailing \r. NFC llvm-svn: 359745 | 7 年前 | |
[LLD] [COFF] Error out if creating a DLL with too many exported symbols The PE/DLL format has a limit on 64k exported symbols per DLL; make sure to check this. Differential Revision: https://reviews.llvm.org/D86701 | 5 年前 | |
COFF: improve link conformance for import names Improve the link conformance for the import name embedded into the import library. This requires the associated change to the LLVM portion for the DEF file parser. The import file generation embeds a different name based on whether the driver is invoked as "link" or "lib". Furthermore, the LIBRARY keyword in the DEF file influences the import name. The behaviour can be summarised according to the following table: | LIBRARY w/ ext | LIBRARY w/o ext | no LIBRARY -----+----------------+---------------------+------------------ LINK | {value} | {value}.{.dll/.exe} | {output name} LIB | {value} | {value}.dll | {output name}.dll llvm-svn: 308407 | 8 年前 | |
Do not allow delay-importing data symbols. If you pass /delayload:<dllname> to the COFF linker, it creates thunks so that DLLs are loaded when they are used for the first time instead of load-time. This mechanism do not work for data symbols as there's no way to trap acccesses to data imported from DLLs. (Technically, I think if we do not initially map dllimport tables in memory, we could actually trap accesses and delay-load data symbols, but that's not what Windows do.) This patch is to report an error when you try to delay-load data symbols. Fixes https://bugs.llvm.org/show_bug.cgi?id=33106 Differential Revision: https://reviews.llvm.org/D33557 llvm-svn: 303890 | 8 年前 | |
[COFF] Fix delay import directory iterator Summary: Take the Index into account in getDelayImportTable, otherwise we always return the entry for the first delay DLL reference. Reviewers: ruiu Reviewed By: ruiu Subscribers: hiraditya, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D60081 llvm-svn: 357697 | 7 年前 | |
[COFF] Fix delay import directory iterator Summary: Take the Index into account in getDelayImportTable, otherwise we always return the entry for the first delay DLL reference. Reviewers: ruiu Reviewed By: ruiu Subscribers: hiraditya, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D60081 llvm-svn: 357697 | 7 年前 | |
[COFF] Link crtend.o as the last object file When faced with command line options such as "crtbegin.o appmain.o -lsomelib crtend.o", GNU ld pulls in all necessary object files from somelib before proceeding to crtend.o. LLD operates differently, only loading object files from any referenced static libraries after processing all input object files. This uses a similar hack as in the ELF linker. Here, it moves crtend.o to the end of the vector of object files. This makes sure that terminator chunks for sections such as .eh_frame gets ordered last, fixing DWARF exception handling for libgcc and gcc's crtend.o. Differential Revision: https://reviews.llvm.org/D60628 llvm-svn: 358394 | 7 年前 | |
[COFF] Link crtend.o as the last object file When faced with command line options such as "crtbegin.o appmain.o -lsomelib crtend.o", GNU ld pulls in all necessary object files from somelib before proceeding to crtend.o. LLD operates differently, only loading object files from any referenced static libraries after processing all input object files. This uses a similar hack as in the ELF linker. Here, it moves crtend.o to the end of the vector of object files. This makes sure that terminator chunks for sections such as .eh_frame gets ordered last, fixing DWARF exception handling for libgcc and gcc's crtend.o. Differential Revision: https://reviews.llvm.org/D60628 llvm-svn: 358394 | 7 年前 | |
lld-link: Implement support for %_PDB% and %_EXT% for /pdbaltpath:. Warn that references to regular env vars are ignored. Fixes PR38940. Differential Revision: https://reviews.llvm.org/D52942 llvm-svn: 344003 | 7 年前 | |
Reland "Change the X86 datalayout to add three address spaces for 32 bit signed, 32 bit unsigned, and 64 bit pointers." This reverts 57076d3199fc2b0af4a3736b7749dd5462cacda5. Original review at https://reviews.llvm.org/D64931. Review for added fix at https://reviews.llvm.org/D66843. llvm-svn: 371568 | 6 年前 | |
[coff] correctly emit safeseh entries for handlers defined in dlls Summary: We previously assumed that all SafeSEH handlers are DefinedRegular symbols. This is not the case for handlers defined in DLLs. As a result, we were failing to emit entries in the SafeSEH table for those handlers. This change fixes that. Fixes PR35324. Reviewers: rnk, ruiu Reviewed By: rnk Subscribers: llvm-commits Differential Revision: https://reviews.llvm.org/D40102 llvm-svn: 318364 | 8 年前 | |
Reland "Change the X86 datalayout to add three address spaces for 32 bit signed, 32 bit unsigned, and 64 bit pointers." This reverts 57076d3199fc2b0af4a3736b7749dd5462cacda5. Original review at https://reviews.llvm.org/D64931. Review for added fix at https://reviews.llvm.org/D66843. llvm-svn: 371568 | 6 年前 | |
[yaml2obj] Updating LLD tests to account for LLVM r273915 This removed the -format flag from yaml2obj in favor of YAML tags. llvm-svn: 273920 | 9 年前 | |
[yaml2obj] Updating LLD tests to account for LLVM r273915 This removed the -format flag from yaml2obj in favor of YAML tags. llvm-svn: 273920 | 9 年前 | |
test: add COFF test for library extension handling Ensure that an extension other than .dll, .exe is preserved as per the behaviour of link. llvm-svn: 308386 | 8 年前 | |
[LLD][COFF] Attempt fix for failifmismatch test on aarch64-only builder. Shall fix: http://lab.llvm.org:8011/builders/clang-cmake-aarch64-lld/builds/6150 llvm-svn: 355595 | 7 年前 | |
[LLD][COFF] Attempt fix for failifmismatch test on aarch64-only builder. Shall fix: http://lab.llvm.org:8011/builders/clang-cmake-aarch64-lld/builds/6150 llvm-svn: 355595 | 7 年前 | |
[COFF] Implement the remaining ARM64 relocations Now only IMAGE_REL_ARM64_ABSOLUTE and IMAGE_REL_ARM64_TOKEN are unhandled. Also add range checks for the existing BRANCH26 relocation. Differential Revision: https://reviews.llvm.org/D46354 llvm-svn: 331505 | 8 年前 | |
COFF: handle multiply defined symbols with different storage If a symbol is locally defined and is DLL imported in another translation unit, and the object with the locally defined version is loaded prior to the imported version, then the linker will fail to resolve the definition of the thunk and return the locally defined symbol. This will then be attempted to be cast to an import thunk, which will clearly fail. Only return the thunk if the symbol is inserted or a thunk is created. Otherwise, report a duplication error. llvm-svn: 312386 | 8 年前 | |
[PDB] Resubmit "Support embedding natvis files in PDBs." This was reverted several times due to what ultimately turned out to be incompatibilities in our serialized hash table format. Several changes went in prior to this to fix those issues since they were more fundamental and independent of supporting injected sources, so now that those are fixed this change should hopefully pass. llvm-svn: 328363 | 8 年前 | |
[PDB] One more fix for hasing GSI records. The reference implementation uses a case-insensitive string comparison for strings of equal length. This will cause the string "tEo" to compare less than "VUo". However we were using a case sensitive comparison, which would generate the opposite outcome. Switch to a case insensitive comparison. Also, when one of the strings contains non-ascii characters, fallback to a straight memcmp. The only way to really test this is with a DIA test. Before this patch, the test will fail (but succeed if link.exe is used instead of lld-link). After the patch, it succeeds even with lld-link. llvm-svn: 336464 | 7 年前 | |
[PDB] Sort globals symbols by name in GSI hash buckets. It seems like the debugger first computes a symbol's bucket, and then does a binary search of entries in the bucket using the symbol's name in order to find it. If the bucket entries are not in sorted order, this obviously won't work. After this patch a couple of simple test cases show that we generate an exactly identical GSI hash stream, which is very nice. llvm-svn: 336405 | 7 年前 | |
[PDB] Sort globals symbols by name in GSI hash buckets. It seems like the debugger first computes a symbol's bucket, and then does a binary search of entries in the bucket using the symbol's name in order to find it. If the bucket entries are not in sorted order, this obviously won't work. After this patch a couple of simple test cases show that we generate an exactly identical GSI hash stream, which is very nice. llvm-svn: 336405 | 7 年前 | |
[PDB] Sort globals symbols by name in GSI hash buckets. It seems like the debugger first computes a symbol's bucket, and then does a binary search of entries in the bucket using the symbol's name in order to find it. If the bucket entries are not in sorted order, this obviously won't work. After this patch a couple of simple test cases show that we generate an exactly identical GSI hash stream, which is very nice. llvm-svn: 336405 | 7 年前 | |
[COFF] Allow automatic dllimport from gnu import libraries 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 | 7 年前 | |
[COFF] Support linking to import libraries from GNU binutils 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 | 7 年前 | |
[COFF] Support linking to import libraries from GNU binutils 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 | 7 年前 | |
[COFF] Support linking to import libraries from GNU binutils 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 | 7 年前 | |
[COFF] Cope with weak aliases produced by GNU tools 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 | 7 年前 | |
[COFF] Cope with weak aliases produced by GNU tools 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 | 7 年前 | |
lld-link: align sections to 16 bytes if referenced from the gfids table Summary: Control flow guard works best when targets it checks are 16-byte aligned. Microsoft's link.exe helps ensure this by aligning code from sections that are referenced from the gfids table to 16 bytes when linking with -guard:cf, even if the original section specifies a smaller alignment. This change implements that behavior in lld-link. See https://crbug.com/857012 for more details. Reviewers: ruiu, hans, thakis, zturner Subscribers: llvm-commits Differential Revision: https://reviews.llvm.org/D48690 llvm-svn: 335864 | 7 年前 | |
Fix linkrepro.test after safeseh:no change Add the @feat.00 flag to the input. llvm-svn: 366244 | 6 年前 | |
COFF: Support import-by-ordinal DLL imports. Symbols exported by DLLs can be imported not by name but by small number or ordinal. Usually, symbols have both ordinals and names, and in that case ordinals are called "hints" and used by the loader as hints. However, symbols can have only ordinals. They are called import-by-ordinal symbols. You need to manage ordinals by hand so that they will never change if you choose to use the feature. But it's supposed to make dynamic linking faster because it needs no string comparison. Not sure if that claim still stands in year 2015, though. Anyways, the feature exists, and this patch implements that. llvm-svn: 238780 | 10 年前 | |
COFF: Support import-by-ordinal DLL imports. Symbols exported by DLLs can be imported not by name but by small number or ordinal. Usually, symbols have both ordinals and names, and in that case ordinals are called "hints" and used by the loader as hints. However, symbols can have only ordinals. They are called import-by-ordinal symbols. You need to manage ordinals by hand so that they will never change if you choose to use the feature. But it's supposed to make dynamic linking faster because it needs no string comparison. Not sure if that claim still stands in year 2015, though. Anyways, the feature exists, and this patch implements that. llvm-svn: 238780 | 10 年前 | |
COFF: Implement safe ICF on rodata using address-significance tables. Differential Revision: https://reviews.llvm.org/D51050 llvm-svn: 340555 | 7 年前 | |
lld-link: Add /force:multipleres extension to make dupe resource diag non-fatal As a side benefit, lld-link now reports more than one duplicate resource entry before exiting with an error even if the new flag is not passed. llvm-svn: 359829 | 7 年前 | |
[COFF] Fix .rsrc sections with differing permissions GNU windres, and MS cvtres (unless the /readonly option is passed) produce read-write .rsrc sections, when creating resource object files. This caused the sections to not be added to the precreated RsrcSec, and therefore not be added to the data directory. Differential Revision: https://reviews.llvm.org/D63837 llvm-svn: 364660 | 6 年前 | |
Garbage collect dllimported symbols. This is a different implementation than r303225 (which was reverted in r303270, re-submitted in r303304 and then re-reverted in r303527). In the previous patch, I tried to add Live bit to each dllimported symbol. It turned out that it didn't work with "oldnames.lib" which contains a lot of weak aliases to dllimported symbols. The way we handle weak aliases is to check if undefined symbols can be resolved using weak aliases, and if so, memcpy the Defined symbols to weak Undefined symbols, so that any references to weak aliases automatically see defined symbols instead of undefined ones. This memcpy happens before MarkLive kicks in. That means we may have multiple copies of dllimported symbols. So turning on one instance's Live bit is not enough. This patch moves the Live bit to dllimport file. Since multiple copies of dllsymbols still point to the same file, we can use it as the central repository to keep track of liveness. Differential Revision: https://reviews.llvm.org/D33520 llvm-svn: 303814 | 8 年前 | |
COFF: Fix import symbol name mangling. For IMPORT_NAME_NOPREFIX symbols, we should remove only one prefix character. llvm-svn: 241854 | 10 年前 | |
[yaml2obj] Updating LLD tests to account for LLVM r273915 This removed the -format flag from yaml2obj in favor of YAML tags. llvm-svn: 273920 | 9 年前 | |
[yaml2obj] Updating LLD tests to account for LLVM r273915 This removed the -format flag from yaml2obj in favor of YAML tags. llvm-svn: 273920 | 9 年前 | |
[yaml2obj] Updating LLD tests to account for LLVM r273915 This removed the -format flag from yaml2obj in favor of YAML tags. llvm-svn: 273920 | 9 年前 | |
[COFF] Cope with GCC produced weak aliases referring to comdat functions 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 | 7 年前 | |
[COFF] Cope with GCC produced weak aliases referring to comdat functions 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 | 7 年前 | |
Reland "Change the X86 datalayout to add three address spaces for 32 bit signed, 32 bit unsigned, and 64 bit pointers." This reverts 57076d3199fc2b0af4a3736b7749dd5462cacda5. Original review at https://reviews.llvm.org/D64931. Review for added fix at https://reviews.llvm.org/D66843. llvm-svn: 371568 | 6 年前 | |
[COFF] Add libcall symbols to the link when LTO is being used llvm-svn: 369694 | 6 年前 | |
[COFF] Add initial support for some ARM64 relocations and import thunks This is enough to link a working hello world executable, with a call to an imported function, a string constant passed to the imported function, and loads from a global variable. Differential Revision: https://reviews.llvm.org/D34964 llvm-svn: 307629 | 8 年前 | |
[LLD][COFF] Support GNU style == aliases D46245 added support for this in llvm-libtool, but while lld-link can also create .lib files from .def files it didn't support aliases. I compared the Inputs/library.def test against the output from llvm-libtool and it matches, except for the fact that lld-link reorders functions for some reason. I have also verified that this fixes a bug I was running into while trying to compile .def files to .lib files in MinGW-w64 (using lld-link instead of llvm-libtool). Differential Revision: https://reviews.llvm.org/D113365 | 4 年前 | |
COFF: ARM: Support import functions. llvm-svn: 243205 | 10 年前 | |
[COFF] Align import address chunks to the pointer size This fixes cases on ARM64 when importing from more than one DLL, in case the imports from the first DLL ended up unaligned. When fixing up a IMAGE_REL_ARM64_PAGEOFFSET_12L, which shifts the offset by the load/store size, check that the shift doesn't discard any bits. (This would also detect if the import address chunks were unaligned.) Differential revision: https://reviews.llvm.org/D35640 llvm-svn: 308585 | 8 年前 | |
[COFF] Align import address chunks to the pointer size This fixes cases on ARM64 when importing from more than one DLL, in case the imports from the first DLL ended up unaligned. When fixing up a IMAGE_REL_ARM64_PAGEOFFSET_12L, which shifts the offset by the load/store size, check that the shift doesn't discard any bits. (This would also detect if the import address chunks were unaligned.) Differential revision: https://reviews.llvm.org/D35640 llvm-svn: 308585 | 8 年前 | |
[COFF] Add integration test for LTO + /guard:cf This tests that LLVM emits the relocations that /guard:cf needs to identify address taken. This was PR36624, which was fixed in r327557. llvm-svn: 327559 | 8 年前 | |
[COFF] Warn for locally imported symbols Locally imported symbols are a very surprising linker feature. link.exe warns for them, and we should warn too. Differential Revision: https://reviews.llvm.org/D41269 llvm-svn: 320792 | 8 年前 | |
[COFF] Warn for locally imported symbols Locally imported symbols are a very surprising linker feature. link.exe warns for them, and we should warn too. Differential Revision: https://reviews.llvm.org/D41269 llvm-svn: 320792 | 8 年前 | |
Reland "Change the X86 datalayout to add three address spaces for 32 bit signed, 32 bit unsigned, and 64 bit pointers." This reverts 57076d3199fc2b0af4a3736b7749dd5462cacda5. Original review at https://reviews.llvm.org/D64931. Review for added fix at https://reviews.llvm.org/D66843. llvm-svn: 371568 | 6 年前 | |
COFF: Handle references from LTO object to lazy symbols correctly. The code generator may create references to runtime library symbols such as __chkstk which were not visible via LTOModule. Handle these cases by loading the object file from the library, but abort if we end up having loaded any bitcode objects. Because loading the object file may have introduced new undefined references, call reportRemainingUndefines again to detect and report them. Differential Revision: http://reviews.llvm.org/D10332 llvm-svn: 239386 | 10 年前 | |
COFF: Handle references from LTO object to lazy symbols correctly. The code generator may create references to runtime library symbols such as __chkstk which were not visible via LTOModule. Handle these cases by loading the object file from the library, but abort if we end up having loaded any bitcode objects. Because loading the object file may have introduced new undefined references, call reportRemainingUndefines again to detect and report them. Differential Revision: http://reviews.llvm.org/D10332 llvm-svn: 239386 | 10 年前 | |
Reland "Change the X86 datalayout to add three address spaces for 32 bit signed, 32 bit unsigned, and 64 bit pointers." This reverts 57076d3199fc2b0af4a3736b7749dd5462cacda5. Original review at https://reviews.llvm.org/D64931. Review for added fix at https://reviews.llvm.org/D66843. llvm-svn: 371568 | 6 年前 | |
Reland "Change the X86 datalayout to add three address spaces for 32 bit signed, 32 bit unsigned, and 64 bit pointers." This reverts 57076d3199fc2b0af4a3736b7749dd5462cacda5. Original review at https://reviews.llvm.org/D64931. Review for added fix at https://reviews.llvm.org/D66843. llvm-svn: 371568 | 6 年前 | |
Reland "Change the X86 datalayout to add three address spaces for 32 bit signed, 32 bit unsigned, and 64 bit pointers." This reverts 57076d3199fc2b0af4a3736b7749dd5462cacda5. Original review at https://reviews.llvm.org/D64931. Review for added fix at https://reviews.llvm.org/D66843. llvm-svn: 371568 | 6 年前 | |
Reland "Change the X86 datalayout to add three address spaces for 32 bit signed, 32 bit unsigned, and 64 bit pointers." This reverts 57076d3199fc2b0af4a3736b7749dd5462cacda5. Original review at https://reviews.llvm.org/D64931. Review for added fix at https://reviews.llvm.org/D66843. llvm-svn: 371568 | 6 年前 | |
Reland "Change the X86 datalayout to add three address spaces for 32 bit signed, 32 bit unsigned, and 64 bit pointers." This reverts 57076d3199fc2b0af4a3736b7749dd5462cacda5. Original review at https://reviews.llvm.org/D64931. Review for added fix at https://reviews.llvm.org/D66843. llvm-svn: 371568 | 6 年前 | |
[yaml2obj] Updating LLD tests to account for LLVM r273915 This removed the -format flag from yaml2obj in favor of YAML tags. llvm-svn: 273920 | 9 年前 | |
[yaml2obj] Updating LLD tests to account for LLVM r273915 This removed the -format flag from yaml2obj in favor of YAML tags. llvm-svn: 273920 | 9 年前 | |
lld-link: Demangle symbols from archives in diagnostics 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 | 6 年前 | |
[LLD] [COFF] Implement MinGW default manifest handling In mingw environments, resources are normally compiled to resource object files directly, instead of letting the linker convert them to COFF format. Since some time, GCC supports the notion of a default manifest object. When invoking the linker, GCC looks for the default manifest object file, and if found in the expected path, it is added to linker commands. The default manifest is one that indicates support for the latest known versions of windows, to implicitly unlock the modern behaviours of certain APIs. Not all mingw/gcc distributions include this file, but e.g. in msys2, the default manifest object is distributed in a separate package (which can be but might not always be installed). This means that even if user projects only use one single resource object file, the linker can end up with two resource object files, and thus needs to support merging them. The default manifest has a language id of zero, and GNU ld has got logic for dropping a manifest with a zero language id, if there's another manifest present with a nonzero language id. If there are multiple manifests with a nonzero language id, the merging process errors out. Differential Revision: https://reviews.llvm.org/D66825 llvm-svn: 370974 | 6 年前 | |
[LLD] [COFF] Implement MinGW default manifest handling In mingw environments, resources are normally compiled to resource object files directly, instead of letting the linker convert them to COFF format. Since some time, GCC supports the notion of a default manifest object. When invoking the linker, GCC looks for the default manifest object file, and if found in the expected path, it is added to linker commands. The default manifest is one that indicates support for the latest known versions of windows, to implicitly unlock the modern behaviours of certain APIs. Not all mingw/gcc distributions include this file, but e.g. in msys2, the default manifest object is distributed in a separate package (which can be but might not always be installed). This means that even if user projects only use one single resource object file, the linker can end up with two resource object files, and thus needs to support merging them. The default manifest has a language id of zero, and GNU ld has got logic for dropping a manifest with a zero language id, if there's another manifest present with a nonzero language id. If there are multiple manifests with a nonzero language id, the merging process errors out. Differential Revision: https://reviews.llvm.org/D66825 llvm-svn: 370974 | 6 年前 | |
[LLD] [COFF] Implement MinGW default manifest handling In mingw environments, resources are normally compiled to resource object files directly, instead of letting the linker convert them to COFF format. Since some time, GCC supports the notion of a default manifest object. When invoking the linker, GCC looks for the default manifest object file, and if found in the expected path, it is added to linker commands. The default manifest is one that indicates support for the latest known versions of windows, to implicitly unlock the modern behaviours of certain APIs. Not all mingw/gcc distributions include this file, but e.g. in msys2, the default manifest object is distributed in a separate package (which can be but might not always be installed). This means that even if user projects only use one single resource object file, the linker can end up with two resource object files, and thus needs to support merging them. The default manifest has a language id of zero, and GNU ld has got logic for dropping a manifest with a zero language id, if there's another manifest present with a nonzero language id. If there are multiple manifests with a nonzero language id, the merging process errors out. Differential Revision: https://reviews.llvm.org/D66825 llvm-svn: 370974 | 6 年前 | |
[LLD] [COFF] Implement MinGW default manifest handling In mingw environments, resources are normally compiled to resource object files directly, instead of letting the linker convert them to COFF format. Since some time, GCC supports the notion of a default manifest object. When invoking the linker, GCC looks for the default manifest object file, and if found in the expected path, it is added to linker commands. The default manifest is one that indicates support for the latest known versions of windows, to implicitly unlock the modern behaviours of certain APIs. Not all mingw/gcc distributions include this file, but e.g. in msys2, the default manifest object is distributed in a separate package (which can be but might not always be installed). This means that even if user projects only use one single resource object file, the linker can end up with two resource object files, and thus needs to support merging them. The default manifest has a language id of zero, and GNU ld has got logic for dropping a manifest with a zero language id, if there's another manifest present with a nonzero language id. If there are multiple manifests with a nonzero language id, the merging process errors out. Differential Revision: https://reviews.llvm.org/D66825 llvm-svn: 370974 | 6 年前 | |
[LLD] [COFF] Implement MinGW default manifest handling In mingw environments, resources are normally compiled to resource object files directly, instead of letting the linker convert them to COFF format. Since some time, GCC supports the notion of a default manifest object. When invoking the linker, GCC looks for the default manifest object file, and if found in the expected path, it is added to linker commands. The default manifest is one that indicates support for the latest known versions of windows, to implicitly unlock the modern behaviours of certain APIs. Not all mingw/gcc distributions include this file, but e.g. in msys2, the default manifest object is distributed in a separate package (which can be but might not always be installed). This means that even if user projects only use one single resource object file, the linker can end up with two resource object files, and thus needs to support merging them. The default manifest has a language id of zero, and GNU ld has got logic for dropping a manifest with a zero language id, if there's another manifest present with a nonzero language id. If there are multiple manifests with a nonzero language id, the merging process errors out. Differential Revision: https://reviews.llvm.org/D66825 llvm-svn: 370974 | 6 年前 | |
[LLD] [COFF] Implement MinGW default manifest handling In mingw environments, resources are normally compiled to resource object files directly, instead of letting the linker convert them to COFF format. Since some time, GCC supports the notion of a default manifest object. When invoking the linker, GCC looks for the default manifest object file, and if found in the expected path, it is added to linker commands. The default manifest is one that indicates support for the latest known versions of windows, to implicitly unlock the modern behaviours of certain APIs. Not all mingw/gcc distributions include this file, but e.g. in msys2, the default manifest object is distributed in a separate package (which can be but might not always be installed). This means that even if user projects only use one single resource object file, the linker can end up with two resource object files, and thus needs to support merging them. The default manifest has a language id of zero, and GNU ld has got logic for dropping a manifest with a zero language id, if there's another manifest present with a nonzero language id. If there are multiple manifests with a nonzero language id, the merging process errors out. Differential Revision: https://reviews.llvm.org/D66825 llvm-svn: 370974 | 6 年前 | |
[lld/COFF] Improve handling of the /manifestdependency: flag If multiple /manifestdependency: flags are passed, they are naively deduped, but after that each of them should have an effect, instead of just the last one. Also, /manifestdependency: flags are allowed in .drectve sections (from #pragma comment(linker, ...). To make the interaction between /manifestdependency: flags enabling manifest by default but /manifest:no overriding this work, add an explict ManifestKind::Default state to represent no explicit /manifest flag being passed. To make /manifestdependency: flags from input file .drectve sections work with /manifest:embed, delay embedded manifest emission until after input files have been read. Differential Revision: https://reviews.llvm.org/D108628 | 4 年前 | |
COFF: Support /manifestinput command line option. Manifest file is a separate or embedded XML file having metadata of an executable. As it is XML, it can contain various types of information. Probably the most popular one is to request escalated priviledges. Usually the linker creates an XML file and embed that file into an executable. However, there's a way to supply an XML file from command line. /manifestniput is it. Apparently it is over-designed here, but if you supply two or more manifest files, then the linker needs to merge the files into a single XML file. A good news is that we don't need to do that ourselves. MT.exe command can do that, so we call the command from the linker in this patch. llvm-svn: 266704 | 10 年前 | |
[lld-link] Support /map option, matching link.exe 's /map output format Added support for /map and /map:[filepath]. The output was derived from Microsoft's Link.exe output when using that same option. Note that /MAPINFO support was not added. The previous implementation of MapFile.cpp/.h was meant for /lldmap, and was renamed to LLDMapFile.cpp/.h MapFile.cpp/.h is now for /MAP However, a small fix was added to lldmap, replacing a std::sort with std::stable_sort to enforce reproducibility. Differential Revision: https://reviews.llvm.org/D70557 | 6 年前 | |
Reland "Change the X86 datalayout to add three address spaces for 32 bit signed, 32 bit unsigned, and 64 bit pointers." This reverts 57076d3199fc2b0af4a3736b7749dd5462cacda5. Original review at https://reviews.llvm.org/D64931. Review for added fix at https://reviews.llvm.org/D66843. llvm-svn: 371568 | 6 年前 | |
Reland "Change the X86 datalayout to add three address spaces for 32 bit signed, 32 bit unsigned, and 64 bit pointers." This reverts 57076d3199fc2b0af4a3736b7749dd5462cacda5. Original review at https://reviews.llvm.org/D64931. Review for added fix at https://reviews.llvm.org/D66843. llvm-svn: 371568 | 6 年前 | |
Add an option to use the MSVC linker to link LTO-generated object files. This patch defines a new command line option, /MSVCLTO, to LLD. If that option is given, LLD invokes link.exe to link LTO-generated object files. This is hacky but useful because link.exe can create PDB files. Differential Revision: https://reviews.llvm.org/D29526 llvm-svn: 294234 | 9 年前 | |
COFF: improve link conformance for import names Improve the link conformance for the import name embedded into the import library. This requires the associated change to the LLVM portion for the DEF file parser. The import file generation embeds a different name based on whether the driver is invoked as "link" or "lib". Furthermore, the LIBRARY keyword in the DEF file influences the import name. The behaviour can be summarised according to the following table: | LIBRARY w/ ext | LIBRARY w/o ext | no LIBRARY -----+----------------+---------------------+------------------ LINK | {value} | {value}.{.dll/.exe} | {output name} LIB | {value} | {value}.dll | {output name}.dll llvm-svn: 308407 | 8 年前 | |
[PDB] Resubmit "Support embedding natvis files in PDBs." This was reverted several times due to what ultimately turned out to be incompatibilities in our serialized hash table format. Several changes went in prior to this to fix those issues since they were more fundamental and independent of supporting injected sources, so now that those are fixed this change should hopefully pass. llvm-svn: 328363 | 8 年前 | |
[PDB] Resubmit "Support embedding natvis files in PDBs." This was reverted several times due to what ultimately turned out to be incompatibilities in our serialized hash table format. Several changes went in prior to this to fix those issues since they were more fundamental and independent of supporting injected sources, so now that those are fixed this change should hopefully pass. llvm-svn: 328363 | 8 年前 | |
[PDB] Resubmit "Support embedding natvis files in PDBs." This was reverted several times due to what ultimately turned out to be incompatibilities in our serialized hash table format. Several changes went in prior to this to fix those issues since they were more fundamental and independent of supporting injected sources, so now that those are fixed this change should hopefully pass. llvm-svn: 328363 | 8 年前 | |
[lld] Fix type server merging with PDBs without IPI stream PDBs may not necessarily contain an IPI stream. Handle this case gracefully. The test case was verified to work with MS link.exe. Patch by Vladimir Panteleev, with a small simplification Reviewed By: rnk Differential Revision: https://reviews.llvm.org/D63178 llvm-svn: 363213 | 6 年前 | |
[lld] Fix type server merging with PDBs without IPI stream PDBs may not necessarily contain an IPI stream. Handle this case gracefully. The test case was verified to work with MS link.exe. Patch by Vladimir Panteleev, with a small simplification Reviewed By: rnk Differential Revision: https://reviews.llvm.org/D63178 llvm-svn: 363213 | 6 年前 | |
COFF: improve link conformance for import names Improve the link conformance for the import name embedded into the import library. This requires the associated change to the LLVM portion for the DEF file parser. The import file generation embeds a different name based on whether the driver is invoked as "link" or "lib". Furthermore, the LIBRARY keyword in the DEF file influences the import name. The behaviour can be summarised according to the following table: | LIBRARY w/ ext | LIBRARY w/o ext | no LIBRARY -----+----------------+---------------------+------------------ LINK | {value} | {value}.{.dll/.exe} | {output name} LIB | {value} | {value}.dll | {output name}.dll llvm-svn: 308407 | 8 年前 | |
Garbage collect dllimported symbols. This is a different implementation than r303225 (which was reverted in r303270, re-submitted in r303304 and then re-reverted in r303527). In the previous patch, I tried to add Live bit to each dllimported symbol. It turned out that it didn't work with "oldnames.lib" which contains a lot of weak aliases to dllimported symbols. The way we handle weak aliases is to check if undefined symbols can be resolved using weak aliases, and if so, memcpy the Defined symbols to weak Undefined symbols, so that any references to weak aliases automatically see defined symbols instead of undefined ones. This memcpy happens before MarkLive kicks in. That means we may have multiple copies of dllimported symbols. So turning on one instance's Live bit is not enough. This patch moves the Live bit to dllimport file. Since multiple copies of dllsymbols still point to the same file, we can use it as the central repository to keep track of liveness. Differential Revision: https://reviews.llvm.org/D33520 llvm-svn: 303814 | 8 年前 | |
Add the /order option. With the /order option, you can give an order file. An order file contains symbol names, one per line, and the linker places comdat sections in that given order. The option is used often to optimize an output binary for (in particular, startup) speed by improving locality. Differential Revision: https://reviews.llvm.org/D42598 llvm-svn: 323579 | 8 年前 | |
[lld] Don't create hints-section if Hint/Name Table is empty Fixes assert in addLinkerModuleCoffGroup() when using by-ordinal imports only. Patch by Stefan Schmidt. Differential revision: https://reviews.llvm.org/D68352 llvm-svn: 374140 | 6 年前 | |
[COFF] Store import symbol pointers as pointers to the base class Future symbol insertions can potentially change the type of these symbols - keep pointers to the base class to reflect this, and use dynamic casts to inspect them before using as the subclass type. This fixes crashes that were possible before, by touching these symbols that now are populated as e.g. a DefinedRegular, via the old pointers with DefinedImportThunk type. Differential Revision: https://reviews.llvm.org/D48953 llvm-svn: 336652 | 7 年前 | |
Fix some differences between lld and MSVC generated PDBs. A couple of things were different about our generated PDBs. 1) We were outputting the wrong Version on the PDB Stream. The version we were setting was newer than what MSVC is setting. It's not clear what the implications are, but we change LLD to use PdbImplVC70, as MSVC does. 2) For the optional debug stream indices in the DBI Stream, we were outputting 0 to mean "the stream is not present". MSVC outputs uint16_t(-1), which is the "correct" way to specify that a stream is not present. So we fix that as well. 3) We were setting the PDB Stream signature to 0. This is supposed to be the result of calling time(nullptr). Although this leads to non-deterministic builds, a better way to solve that is by having a command line option explicitly for generating a reproducible build, and have the default behavior of lld-link match the default behavior of link. To test this, I'm making use of the new and improved pdb diff sub command. To make it suitable for writing tests against, I had to modify the diff subcommand slightly to print less verbose output. Previously it would always print | <column> | <value1> | <value2> | which is quite verbose, and the values are fragile. All we really want to know is "did we produce the same value as link?" So I added command line options to print a single character representing the result status (different, identical, equivalent), and another to hide the value display. Note that just inspecting the diff output used to write the test, you can see some things that are obviously wrong. That is just reflective of the fact that this is the state of affairs today, not that we're asserting that this is "correct". We can use this as a starting point to discover differences, fix them, and update the test. Differential Revision: https://reviews.llvm.org/D35086 llvm-svn: 307422 | 8 年前 | |
Delete trailing \r. NFC llvm-svn: 359745 | 7 年前 | |
Fix some differences between lld and MSVC generated PDBs. A couple of things were different about our generated PDBs. 1) We were outputting the wrong Version on the PDB Stream. The version we were setting was newer than what MSVC is setting. It's not clear what the implications are, but we change LLD to use PdbImplVC70, as MSVC does. 2) For the optional debug stream indices in the DBI Stream, we were outputting 0 to mean "the stream is not present". MSVC outputs uint16_t(-1), which is the "correct" way to specify that a stream is not present. So we fix that as well. 3) We were setting the PDB Stream signature to 0. This is supposed to be the result of calling time(nullptr). Although this leads to non-deterministic builds, a better way to solve that is by having a command line option explicitly for generating a reproducible build, and have the default behavior of lld-link match the default behavior of link. To test this, I'm making use of the new and improved pdb diff sub command. To make it suitable for writing tests against, I had to modify the diff subcommand slightly to print less verbose output. Previously it would always print | <column> | <value1> | <value2> | which is quite verbose, and the values are fragile. All we really want to know is "did we produce the same value as link?" So I added command line options to print a single character representing the result status (different, identical, equivalent), and another to hide the value display. Note that just inspecting the diff output used to write the test, you can see some things that are obviously wrong. That is just reflective of the fact that this is the state of affairs today, not that we're asserting that this is "correct". We can use this as a starting point to discover differences, fix them, and update the test. Differential Revision: https://reviews.llvm.org/D35086 llvm-svn: 307422 | 8 年前 | |
[COFF] Fix relocation offsets in pdb-file-statics test input The relocation offsets were incorrect. I fixed them with llvm-readobj -codeview -codeview-subsection-bytes, which has a helpful printout of the relocations that apply to a given symbol record with their offsets. With this, I was able to update the relocation offsets in the yaml to fix the line table and the S_DEFRANGE_REGISTER records. There is still some remaining inconsistency in yaml2obj and obj2yaml when round tripping MSVC objects, but that isn't a blocker for relanding D94267. | 5 年前 | |
[COFF] Update LLD yaml test cases to include .bss size These yaml test cases appear to have been affected by PR41836 Right now what happens is that these empty .bss sections are merged into .data, then the .data output section ends up having a zero virtual size, and it is discarded from the output after addresses are assigned. However, we've already assigned OutputSections to Chunks, so we don't correctly report the zero-sized chunks that were in there as having been discarded. Soon, we will report them as discarded, so these test cases need to be updated to have a non-zero size so they aren't discarded. llvm-svn: 360476 | 7 年前 | |
Deduplicate S_CONSTANTs in LLD. Summary: Deduplicate S_CONSTANTS when linking, if they have the same value. Reviewers: rnk Subscribers: hiraditya, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D63151 llvm-svn: 363089 | 6 年前 | |
Deduplicate S_CONSTANTs in LLD. Summary: Deduplicate S_CONSTANTS when linking, if they have the same value. Reviewers: rnk Subscribers: hiraditya, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D63151 llvm-svn: 363089 | 6 年前 | |
[COFF] Allow debug info to relocate against discarded symbols Summary: In order to do this without switching on the symbol kind multiple times, I created Defined::getChunkAndOffset and use that instead of SymbolBody::getRVA in the inner relocation loop. Now we get the symbol's chunk before switching over relocation types, so we can test if it has been discarded outside the inner relocation type switch. This also simplifies application of section relative relocations. Previously we would switch on symbol kind to compute the RVA, then the relocation type, and then the symbol kind again to get the output section so we could subtract that from the symbol RVA. Now we *always* have an OutputSection, so applying SECREL and SECTION relocations isn't as much of a special case. I'm still not quite happy with the cleanliness of this code. I'm not sure what offsets and bases we should be using during the relocation processing loop: VA, RVA, or OutputSectionOffset. Reviewers: ruiu, pcc Reviewed By: ruiu Subscribers: majnemer, inglorion, llvm-commits, aprantl Differential Revision: https://reviews.llvm.org/D34650 llvm-svn: 306566 | 8 年前 | |
[LLD][COFF] Move debug info for thread-local variables into PDB global stream Before this patch, the debug record S_GTHREAD32 which represents global thread_local symbols, was emitted by LLD into the respective module stream. This makes Visual Studio unable to display thread_local symbols in the debugger. After this patch, S_GTHREAD32 is moved into the globals stream. This matches MSVC behavior. Differential Revision: https://reviews.llvm.org/D79005 | 6 年前 | |
Resubmit [pdb] Change /DEBUG:GHASH to emit 8 byte hashes." This fixes the remaining failing tests, so resubmitting with no functional change. llvm-svn: 332676 | 7 年前 | |
Resubmit [pdb] Change /DEBUG:GHASH to emit 8 byte hashes." This fixes the remaining failing tests, so resubmitting with no functional change. llvm-svn: 332676 | 7 年前 | |
Resubmit [pdb] Change /DEBUG:GHASH to emit 8 byte hashes." This fixes the remaining failing tests, so resubmitting with no functional change. llvm-svn: 332676 | 7 年前 | |
[COFF] Allow debug info to relocate against discarded symbols Summary: In order to do this without switching on the symbol kind multiple times, I created Defined::getChunkAndOffset and use that instead of SymbolBody::getRVA in the inner relocation loop. Now we get the symbol's chunk before switching over relocation types, so we can test if it has been discarded outside the inner relocation type switch. This also simplifies application of section relative relocations. Previously we would switch on symbol kind to compute the RVA, then the relocation type, and then the symbol kind again to get the output section so we could subtract that from the symbol RVA. Now we *always* have an OutputSection, so applying SECREL and SECTION relocations isn't as much of a special case. I'm still not quite happy with the cleanliness of this code. I'm not sure what offsets and bases we should be using during the relocation processing loop: VA, RVA, or OutputSectionOffset. Reviewers: ruiu, pcc Reviewed By: ruiu Subscribers: majnemer, inglorion, llvm-commits, aprantl Differential Revision: https://reviews.llvm.org/D34650 llvm-svn: 306566 | 8 年前 | |
Update LLD tests for CodeView dumper change in r339907 llvm-svn: 339913 | 7 年前 | |
Update LLD tests for CodeView dumper change in r339907 llvm-svn: 339913 | 7 年前 | |
[lld][COFF] Fix TypeServerSource lookup on GUID collisions Microsoft shipped a bunch of PDB files with broken/invalid GUIDs which lead lld to use 0xFF as the key for these files in an internal cache. When multiple files have this key it will lead to collisions and confused symbol lookup. Several approaches to fix this was considered. Including making the key the path to the PDB file, but this requires some filesystem operations in order to normalize the file path. Since this only happens with malformatted PDB files and we haven't seen this before they malformatted files where shipped with visual studio we probably shouldn't optimize for this use-case. Instead we now just don't insert files with Guid == 0xFF into the cache map and warn if we get collisions so similar problems can be found in the future instead of being silent. Discussion about the root issue and the approach to this fix can be found on Github: https://github.com/llvm/llvm-project/issues/54487 Reviewed By: aganea Differential Revision: https://reviews.llvm.org/D122372 | 4 年前 | |
[lld][COFF] Fix TypeServerSource lookup on GUID collisions Microsoft shipped a bunch of PDB files with broken/invalid GUIDs which lead lld to use 0xFF as the key for these files in an internal cache. When multiple files have this key it will lead to collisions and confused symbol lookup. Several approaches to fix this was considered. Including making the key the path to the PDB file, but this requires some filesystem operations in order to normalize the file path. Since this only happens with malformatted PDB files and we haven't seen this before they malformatted files where shipped with visual studio we probably shouldn't optimize for this use-case. Instead we now just don't insert files with Guid == 0xFF into the cache map and warn if we get collisions so similar problems can be found in the future instead of being silent. Discussion about the root issue and the approach to this fix can be found on Github: https://github.com/llvm/llvm-project/issues/54487 Reviewed By: aganea Differential Revision: https://reviews.llvm.org/D122372 | 4 年前 | |
[lld][COFF] Fix TypeServerSource lookup on GUID collisions Microsoft shipped a bunch of PDB files with broken/invalid GUIDs which lead lld to use 0xFF as the key for these files in an internal cache. When multiple files have this key it will lead to collisions and confused symbol lookup. Several approaches to fix this was considered. Including making the key the path to the PDB file, but this requires some filesystem operations in order to normalize the file path. Since this only happens with malformatted PDB files and we haven't seen this before they malformatted files where shipped with visual studio we probably shouldn't optimize for this use-case. Instead we now just don't insert files with Guid == 0xFF into the cache map and warn if we get collisions so similar problems can be found in the future instead of being silent. Discussion about the root issue and the approach to this fix can be found on Github: https://github.com/llvm/llvm-project/issues/54487 Reviewed By: aganea Differential Revision: https://reviews.llvm.org/D122372 | 4 年前 | |
[lld][COFF] Fix TypeServerSource lookup on GUID collisions Microsoft shipped a bunch of PDB files with broken/invalid GUIDs which lead lld to use 0xFF as the key for these files in an internal cache. When multiple files have this key it will lead to collisions and confused symbol lookup. Several approaches to fix this was considered. Including making the key the path to the PDB file, but this requires some filesystem operations in order to normalize the file path. Since this only happens with malformatted PDB files and we haven't seen this before they malformatted files where shipped with visual studio we probably shouldn't optimize for this use-case. Instead we now just don't insert files with Guid == 0xFF into the cache map and warn if we get collisions so similar problems can be found in the future instead of being silent. Discussion about the root issue and the approach to this fix can be found on Github: https://github.com/llvm/llvm-project/issues/54487 Reviewed By: aganea Differential Revision: https://reviews.llvm.org/D122372 | 4 年前 | |
[lld] Fixed CodeView GuidAdapter::format to handle GUID bytes in the right order. This fixes https://bugs.llvm.org/show_bug.cgi?id=41712 bug. Reviewed By: aganea Differential Revision: https://reviews.llvm.org/D99978 | 5 年前 | |
[lld] Fixed CodeView GuidAdapter::format to handle GUID bytes in the right order. This fixes https://bugs.llvm.org/show_bug.cgi?id=41712 bug. Reviewed By: aganea Differential Revision: https://reviews.llvm.org/D99978 | 5 年前 | |
Update LLD tests for CodeView dumper change in r339907 llvm-svn: 339913 | 7 年前 | |
Update LLD tests for CodeView dumper change in r339907 llvm-svn: 339913 | 7 年前 | |
[PDB] Merge in types and items from type servers (/Zi) Summary: Object files compiled with /Zi emit type information into a type server PDB. The .debug$S section will contain a single TypeServer2Record with the absolute path and GUID of the type server. LLD needs to load the type server PDB and merge all types and items it finds in it into the destination PDB. Depends on D35495 Reviewers: ruiu, inglorion Subscribers: zturner, llvm-commits Differential Revision: https://reviews.llvm.org/D35504 llvm-svn: 308235 | 8 年前 | |
[lld] Fixed CodeView GuidAdapter::format to handle GUID bytes in the right order. This fixes https://bugs.llvm.org/show_bug.cgi?id=41712 bug. Reviewed By: aganea Differential Revision: https://reviews.llvm.org/D99978 | 5 年前 | |
[codeview] YAMLize all section offsets and indices in symbol records We forgot to serialize these because llvm-readobj didn't dump them. They are typically all zeros in an object file. The linker fills them in with relocations before adding them to the PDB. Now we can properly round trip these symbols through pdb2yaml -> yaml2pdb. I made these fields optional with a zero default so that we can elide them from our test cases. llvm-svn: 305857 | 8 年前 | |
Resubmit "[codeview] Make obj2yaml/yaml2obj support .debug$S..." This was originally reverted because of some non-deterministic failures on certain buildbots. Luckily ASAN eventually caught this as a stack-use-after-scope, so the fix is included in this patch. llvm-svn: 305393 | 8 年前 | |
[COFF] Update LLD yaml test cases to include .bss size These yaml test cases appear to have been affected by PR41836 Right now what happens is that these empty .bss sections are merged into .data, then the .data output section ends up having a zero virtual size, and it is discarded from the output after addresses are assigned. However, we've already assigned OutputSections to Chunks, so we don't correctly report the zero-sized chunks that were in there as having been discarded. Soon, we will report them as discarded, so these test cases need to be updated to have a non-zero size so they aren't discarded. llvm-svn: 360476 | 7 年前 | |
Remove trailing whitespace. llvm-svn: 320520 | 8 年前 | |
Remove trailing whitespace. llvm-svn: 320520 | 8 年前 | |
Re-land [CodeView] Add full repro to LF_BUILDINFO record This patch writes the full -cc1 command into the resulting .OBJ, like MSVC does. This allows for external tools (Recode, Live++) to rebuild a source file without any external dependency but the .OBJ itself (other than the compiler) and without knowledge of the build system. The LF_BUILDINFO record stores a full path to the compiler, the PWD (CWD at program startup), a relative or absolute path to the source, and the full CC1 command line. The stored command line is self-standing (does not depend on the environment). In the same way, MSVC doesn't exactly store the provided command-line, but an expanded version (a somehow equivalent of CC1) which is also self-standing. For more information see PR36198 and D43002. Differential Revision: https://reviews.llvm.org/D80833 | 4 年前 | |
Remove trailing whitespace. llvm-svn: 320520 | 8 年前 | |
Re-land [CodeView] Add full repro to LF_BUILDINFO record This patch writes the full -cc1 command into the resulting .OBJ, like MSVC does. This allows for external tools (Recode, Live++) to rebuild a source file without any external dependency but the .OBJ itself (other than the compiler) and without knowledge of the build system. The LF_BUILDINFO record stores a full path to the compiler, the PWD (CWD at program startup), a relative or absolute path to the source, and the full CC1 command line. The stored command line is self-standing (does not depend on the environment). In the same way, MSVC doesn't exactly store the provided command-line, but an expanded version (a somehow equivalent of CC1) which is also self-standing. For more information see PR36198 and D43002. Differential Revision: https://reviews.llvm.org/D80833 | 4 年前 | |
[COFF][LLD] Add link support for Microsoft precompiled headers OBJs 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 | 7 年前 | |
[COFF][LLD] Add link support for Microsoft precompiled headers OBJs 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 | 7 年前 | |
[LLD][COFF] When using PCH.OBJ, ensure func_id records indices are remapped under /DEBUG:GHASH Before this patch, when using LLD with /DEBUG:GHASH and MSVC precomp.OBJ files, we had a bunch of: lld-link: warning: S_[GL]PROC32ID record in blabla.obj refers to PDB item index 0x206ED1 which is not a LF[M]FUNC_ID record This was caused by LF_FUNC_ID and LF_MFUNC_ID which didn't have correct mapping to the corresponding TPI records. The root issue was that the indexMapStorage was improperly re-assembled in UsePrecompSource::remapTpiWithGHashes. After this patch, /DEBUG and /DEBUG:GHASH produce exactly the same debug infos in the PDB. Differential Revision: https://reviews.llvm.org/D93732 | 5 年前 | |
[LLD][COFF] When using PCH.OBJ, ensure func_id records indices are remapped under /DEBUG:GHASH Before this patch, when using LLD with /DEBUG:GHASH and MSVC precomp.OBJ files, we had a bunch of: lld-link: warning: S_[GL]PROC32ID record in blabla.obj refers to PDB item index 0x206ED1 which is not a LF[M]FUNC_ID record This was caused by LF_FUNC_ID and LF_MFUNC_ID which didn't have correct mapping to the corresponding TPI records. The root issue was that the indexMapStorage was improperly re-assembled in UsePrecompSource::remapTpiWithGHashes. After this patch, /DEBUG and /DEBUG:GHASH produce exactly the same debug infos in the PDB. Differential Revision: https://reviews.llvm.org/D93732 | 5 年前 | |
[LLD][COFF] When using PCH.OBJ, ensure func_id records indices are remapped under /DEBUG:GHASH Before this patch, when using LLD with /DEBUG:GHASH and MSVC precomp.OBJ files, we had a bunch of: lld-link: warning: S_[GL]PROC32ID record in blabla.obj refers to PDB item index 0x206ED1 which is not a LF[M]FUNC_ID record This was caused by LF_FUNC_ID and LF_MFUNC_ID which didn't have correct mapping to the corresponding TPI records. The root issue was that the indexMapStorage was improperly re-assembled in UsePrecompSource::remapTpiWithGHashes. After this patch, /DEBUG and /DEBUG:GHASH produce exactly the same debug infos in the PDB. Differential Revision: https://reviews.llvm.org/D93732 | 5 年前 | |
[COFF][LLD] Add link support for Microsoft precompiled headers OBJs 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 | 7 年前 | |
[COFF][LLD] Add link support for Microsoft precompiled headers OBJs 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 | 7 年前 | |
[LLD][COFF] Fix crash with /summary and PCH input files Before this patch /summary was crashing with some .PCH.OBJ files, because tpiMap[srcIdx++] was reading at the wrong location. When the TpiSource depends on a .PCH.OBJ file, the types should be offset by the previously merged PCH.OBJ set of indices. Differential Revision: https://reviews.llvm.org/D88678 | 5 年前 | |
[LLD][COFF] Fix crash with /summary and PCH input files Before this patch /summary was crashing with some .PCH.OBJ files, because tpiMap[srcIdx++] was reading at the wrong location. When the TpiSource depends on a .PCH.OBJ file, the types should be offset by the previously merged PCH.OBJ set of indices. Differential Revision: https://reviews.llvm.org/D88678 | 5 年前 | |
COFF: Support Windows resource files. Resource files are data files containing i18n messages, icon images, etc. MSVC has a tool to convert a resource file to a regular COFF file so that you can just link that file to embed resources to an executable. However, you can directly pass resource files to the linker. If you do that, the linker invokes the tool automatically. This patch implements that feature. llvm-svn: 239704 | 10 年前 | |
COFF: Move machine type auto-detection to SymbolTable. The new mechanism is less code, and fixes the case where all inputs are archives. Differential Revision: http://reviews.llvm.org/D10136 llvm-svn: 238618 | 10 年前 | |
COFF: Add a new PE/COFF port. This is an initial patch for a section-based COFF linker. The patch has 2300 lines of code including comments and blank lines. Before diving into details, you want to start from reading README because it should give you an overview of the design. All important things are written in the README file, so I write summary here. - The linker is already able to self-link on Windows. - It's significantly faster than the existing implementation. The existing one takes 5 seconds to link LLD on my machine, while the new one only takes 1.2 seconds, even though the new one is not multi-threaded yet. (And a proof-of-concept multi- threaded version was able to link it in 0.5 seconds.) - It uses much less memory (250MB vs. 2GB virtual memory space to self-host). - IMHO the new code is much simpler and easier to read than the existing PE/COFF port. http://reviews.llvm.org/D10036 llvm-svn: 238458 | 10 年前 | |
[yaml2obj] Updating LLD tests to account for LLVM r273915 This removed the -format flag from yaml2obj in favor of YAML tags. llvm-svn: 273920 | 9 年前 | |
reland "[lld-link] implement -start-lib and -end-lib" 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 | 6 年前 | |
reland "[lld-link] implement -start-lib and -end-lib" 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 | 6 年前 | |
COFF: Support 32-bit x86 DLL import table. llvm-svn: 241767 | 10 年前 | |
COFF: Support import-by-ordinal DLL imports. Symbols exported by DLLs can be imported not by name but by small number or ordinal. Usually, symbols have both ordinals and names, and in that case ordinals are called "hints" and used by the loader as hints. However, symbols can have only ordinals. They are called import-by-ordinal symbols. You need to manage ordinals by hand so that they will never change if you choose to use the feature. But it's supposed to make dynamic linking faster because it needs no string comparison. Not sure if that claim still stands in year 2015, though. Anyways, the feature exists, and this patch implements that. llvm-svn: 238780 | 10 年前 | |
[ms] Add new /PDBSTREAM option to lld-link allowing injection of streams into PDB files. Summary: /PDBSTREAM:<name>=<file> adds the contents of <file> to stream <name> in the resulting PDB. This allows native uses with workflows that (for example) add srcsrv streams to PDB files to provide a location for the build's source files. Results should be equivalent to linking with lld-link, then running Microsoft's pdbstr tool with the command line: pdbstr.exe -w -p:<PDB LOCATION> -s:<name> -i:<file> except in cases where the named stream overlaps with a default named stream, such as "/names". In those cases, the added stream will be overridden, making the /pdbstream option a no-op. Reviewers: thakis, rnk Reviewed By: thakis Differential Revision: https://reviews.llvm.org/D77310 | 6 年前 | |
Reland "Change the X86 datalayout to add three address spaces for 32 bit signed, 32 bit unsigned, and 64 bit pointers." This reverts 57076d3199fc2b0af4a3736b7749dd5462cacda5. Original review at https://reviews.llvm.org/D64931. Review for added fix at https://reviews.llvm.org/D66843. llvm-svn: 371568 | 6 年前 | |
Reland "Change the X86 datalayout to add three address spaces for 32 bit signed, 32 bit unsigned, and 64 bit pointers." This reverts 57076d3199fc2b0af4a3736b7749dd5462cacda5. Original review at https://reviews.llvm.org/D64931. Review for added fix at https://reviews.llvm.org/D66843. llvm-svn: 371568 | 6 年前 | |
Reland "Change the X86 datalayout to add three address spaces for 32 bit signed, 32 bit unsigned, and 64 bit pointers." This reverts 57076d3199fc2b0af4a3736b7749dd5462cacda5. Original review at https://reviews.llvm.org/D64931. Review for added fix at https://reviews.llvm.org/D66843. llvm-svn: 371568 | 6 年前 | |
[LLD] Add baseline test for TLS alignment. NFC. Reviewed By: rnk Differential Revision: https://reviews.llvm.org/D88646 | 5 年前 | |
[LLD] Add baseline test for TLS alignment. NFC. Reviewed By: rnk Differential Revision: https://reviews.llvm.org/D88646 | 5 年前 | |
[test] Fix the test from the previous commit when run on windows. NFC. Apparently the escaped dollar sign didn't work the same way in "echo -e" on windows buildbots. llvm-svn: 366784 | 6 年前 | |
Revert "[NFC] remove explicit default value for strboolattr attribute in tests" This reverts commit bda6e5bee04c75b1f1332b4fd1ac4e8ef6c3c247. See https://lab.llvm.org/buildbot/#/builders/109/builds/15424 for instance | 5 年前 | |
Revert "[NFC] remove explicit default value for strboolattr attribute in tests" This reverts commit bda6e5bee04c75b1f1332b4fd1ac4e8ef6c3c247. See https://lab.llvm.org/buildbot/#/builders/109/builds/15424 for instance | 5 年前 | |
Revert "[NFC] remove explicit default value for strboolattr attribute in tests" This reverts commit bda6e5bee04c75b1f1332b4fd1ac4e8ef6c3c247. See https://lab.llvm.org/buildbot/#/builders/109/builds/15424 for instance | 5 年前 | |
Reland "Change the X86 datalayout to add three address spaces for 32 bit signed, 32 bit unsigned, and 64 bit pointers." This reverts 57076d3199fc2b0af4a3736b7749dd5462cacda5. Original review at https://reviews.llvm.org/D64931. Review for added fix at https://reviews.llvm.org/D66843. llvm-svn: 371568 | 6 年前 | |
Reland "Change the X86 datalayout to add three address spaces for 32 bit signed, 32 bit unsigned, and 64 bit pointers." This reverts 57076d3199fc2b0af4a3736b7749dd5462cacda5. Original review at https://reviews.llvm.org/D64931. Review for added fix at https://reviews.llvm.org/D66843. llvm-svn: 371568 | 6 年前 | |
Reland "Change the X86 datalayout to add three address spaces for 32 bit signed, 32 bit unsigned, and 64 bit pointers." This reverts 57076d3199fc2b0af4a3736b7749dd5462cacda5. Original review at https://reviews.llvm.org/D64931. Review for added fix at https://reviews.llvm.org/D66843. llvm-svn: 371568 | 6 年前 |
| 文件 | 最后提交记录 | 最后更新时间 |
|---|---|---|
| 6 年前 | ||
| 6 年前 | ||
| 6 年前 | ||
| 8 年前 | ||
| 9 年前 | ||
| 10 年前 | ||
| 8 年前 | ||
| 7 年前 | ||
| 7 年前 | ||
| 6 年前 | ||
| 8 年前 | ||
| 9 年前 | ||
| 7 年前 | ||
| 8 年前 | ||
| 6 年前 | ||
| 8 年前 | ||
| 8 年前 | ||
| 8 年前 | ||
| 8 年前 | ||
| 6 年前 | ||
| 5 年前 | ||
| 7 年前 | ||
| 5 年前 | ||
| 7 年前 | ||
| 6 年前 | ||
| 6 年前 | ||
| 9 年前 | ||
| 7 年前 | ||
| 7 年前 | ||
| 5 年前 | ||
| 8 年前 | ||
| 8 年前 | ||
| 7 年前 | ||
| 7 年前 | ||
| 7 年前 | ||
| 7 年前 | ||
| 7 年前 | ||
| 6 年前 | ||
| 8 年前 | ||
| 6 年前 | ||
| 9 年前 | ||
| 9 年前 | ||
| 8 年前 | ||
| 7 年前 | ||
| 7 年前 | ||
| 8 年前 | ||
| 8 年前 | ||
| 8 年前 | ||
| 7 年前 | ||
| 7 年前 | ||
| 7 年前 | ||
| 7 年前 | ||
| 7 年前 | ||
| 7 年前 | ||
| 7 年前 | ||
| 7 年前 | ||
| 7 年前 | ||
| 7 年前 | ||
| 7 年前 | ||
| 6 年前 | ||
| 10 年前 | ||
| 10 年前 | ||
| 7 年前 | ||
| 7 年前 | ||
| 6 年前 | ||
| 8 年前 | ||
| 10 年前 | ||
| 9 年前 | ||
| 9 年前 | ||
| 9 年前 | ||
| 7 年前 | ||
| 7 年前 | ||
| 6 年前 | ||
| 6 年前 | ||
| 8 年前 | ||
| 4 年前 | ||
| 10 年前 | ||
| 8 年前 | ||
| 8 年前 | ||
| 8 年前 | ||
| 8 年前 | ||
| 8 年前 | ||
| 6 年前 | ||
| 10 年前 | ||
| 10 年前 | ||
| 6 年前 | ||
| 6 年前 | ||
| 6 年前 | ||
| 6 年前 | ||
| 6 年前 | ||
| 9 年前 | ||
| 9 年前 | ||
| 6 年前 | ||
| 6 年前 | ||
| 6 年前 | ||
| 6 年前 | ||
| 6 年前 | ||
| 6 年前 | ||
| 6 年前 | ||
| 4 年前 | ||
| 10 年前 | ||
| 6 年前 | ||
| 6 年前 | ||
| 6 年前 | ||
| 9 年前 | ||
| 8 年前 | ||
| 8 年前 | ||
| 8 年前 | ||
| 8 年前 | ||
| 6 年前 | ||
| 6 年前 | ||
| 8 年前 | ||
| 8 年前 | ||
| 8 年前 | ||
| 6 年前 | ||
| 7 年前 | ||
| 8 年前 | ||
| 7 年前 | ||
| 8 年前 | ||
| 5 年前 | ||
| 7 年前 | ||
| 6 年前 | ||
| 6 年前 | ||
| 8 年前 | ||
| 6 年前 | ||
| 7 年前 | ||
| 7 年前 | ||
| 7 年前 | ||
| 8 年前 | ||
| 7 年前 | ||
| 7 年前 | ||
| 4 年前 | ||
| 4 年前 | ||
| 4 年前 | ||
| 4 年前 | ||
| 5 年前 | ||
| 5 年前 | ||
| 7 年前 | ||
| 7 年前 | ||
| 8 年前 | ||
| 5 年前 | ||
| 8 年前 | ||
| 8 年前 | ||
| 7 年前 | ||
| 8 年前 | ||
| 8 年前 | ||
| 4 年前 | ||
| 8 年前 | ||
| 4 年前 | ||
| 7 年前 | ||
| 7 年前 | ||
| 5 年前 | ||
| 5 年前 | ||
| 5 年前 | ||
| 7 年前 | ||
| 7 年前 | ||
| 5 年前 | ||
| 5 年前 | ||
| 10 年前 | ||
| 10 年前 | ||
| 10 年前 | ||
| 9 年前 | ||
| 6 年前 | ||
| 6 年前 | ||
| 10 年前 | ||
| 10 年前 | ||
| 6 年前 | ||
| 6 年前 | ||
| 6 年前 | ||
| 6 年前 | ||
| 5 年前 | ||
| 5 年前 | ||
| 6 年前 | ||
| 5 年前 | ||
| 5 年前 | ||
| 5 年前 | ||
| 6 年前 | ||
| 6 年前 | ||
| 6 年前 |
