summaryrefslogtreecommitdiffstats
path: root/llvm/lib/Object/COFFModuleDefinition.cpp
Commit message (Collapse)AuthorAgeFilesLines
* Update the file headers across all of the LLVM projects in the monorepoChandler Carruth2019-01-191-4/+3
| | | | | | | | | | | | | | | | | to reflect the new license. We understand that people may be surprised that we're moving the header entirely to discuss the new license. We checked this carefully with the Foundation's lawyer and we believe this is the correct approach. Essentially, all code in the project is now made available by the LLVM project under our new license, so you will see that the license headers include that license only. Some of our contributors have contributed code under our old license, and accordingly, we have retained a copy of our old license notice in the top-level files in each project and repository. llvm-svn: 351636
* [COFF] Improve correctness of def parsing for GNU featuresMartin Storsjo2018-05-091-2/+11
| | | | | | | | | | | | | | | | | | | | | | | | The operator == used for exporting a function with a different name in the DLL compared to the name in the import library (which is useful for adding linker level aliases for function in the import library) is a feature distinct and different from the operator = used for exporting a function with a different name (both in import library and DLL) than in the implementation producing the DLL. When creating an import library using dlltool, from a def file that contains forwards (Func = OtherDll.Func), this shouldn't affect the produced import library, which should still behave just as if it was a normal exported function. This clears a lot of confusion and subtle misunderstandings, and avoids a parameter that was used to avoid creating weak aliases when invoked from lld. (This parameter was added previously due to the existing conflation of the two features.) Differential Revision: https://reviews.llvm.org/D46245 llvm-svn: 331859
* [COFF] Ignore semicolons in module definition identifiersRui Ueyama2017-12-061-1/+1
| | | | | | | | | | | | | | | | Patch by David Major. The NSS project's .def files make heavy use of semicolons in a frightening attempt at portability: https://hg.mozilla.org/projects/nss/raw-file/tip/lib/ckfw/capi/nsscapi.def lld-link was treating the semicolon as part of the export name, resulting in unresolved symbols. This patch includes ';' in the list of characters to split on. Differential Revision: https://reviews.llvm.org/D39968 llvm-svn: 319933
* [COFF] Support ordinals in def files with space between @ and the numberMartin Storsjo2017-10-261-3/+8
| | | | | | | | | | Both GNU ld and MS link.exe support declaring ordinals this way. A test will be added in lld. Differential Revision: https://reviews.llvm.org/D39327 llvm-svn: 316690
* [COFF] Improve the check for functions that should get an extra underscoreMartin Storsjo2017-10-231-3/+21
| | | | | | | | | | | This fixes exporting functions starting with an underscore, and fully decorated fastcall/vectorcall functions. Tests will be added in the lld repo. Differential Revision: https://reviews.llvm.org/D39168 llvm-svn: 316316
* [llvm-dlltool] Fix creating stdcall/fastcall import libraries for i386Martin Storsjo2017-08-161-1/+7
| | | | | | | | | | | | | | | | | | | | | Hook up the -k option (that in the original GNU dlltool removes the @n suffix from the symbol that the final executable ends up linked to). In llvm-dlltool, make sure that functions end up with the undecorate name type if this option is set and they are decorated. In mingw, when creating import libraries from def files instead of creating an import library as a side effect of linking a DLL, the symbol names in the def contain the stdcall/fastcall decoration (but no leading underscore). By setting the undecorate name type, a linker linking to the import library will omit the decoration from the DLL import entry. With this in place, mingw-w64 for i386 built with llvm-dlltool/clang produces import libraries that actually work. Differential Revision: https://reviews.llvm.org/D36548 llvm-svn: 310990
* Object: preserve more information about DEF fileSaleem Abdulrasool2017-07-191-4/+8
| | | | | | | | | | | | Preserve the actual library name as provided by the user. This is required to properly replicate link's behaviour about the module import name handling. This requires an associated change to lld for updating the tests for the proper behaviour for the import library module name handling in various cases. Associated tests will be part of the lld change. llvm-svn: 308406
* Object: handle extensions properly in def filesSaleem Abdulrasool2017-07-181-3/+3
| | | | | | | | | | | | When given an extension as part of the `library` directive in a def file, the extension is preserved/honoured by link/lib. Behave similarly when parsing the def file. This requires checking if a native extension is provided as a keyword parameter. If no extension is present, append a standard `.dll` or `.exe` extension. This is best tested via lld, and I will add tests there as a follow up. llvm-svn: 308383
* llvm: add llvm-dlltool support to the archiverMartell Malone2017-07-181-7/+15
| | | | | | | | | | | | | | | | A PE COFF spec compliant import library generator. Intended to be used with mingw-w64. Supports: PE COFF spec (section 8, Import Library Format) PE COFF spec (Aux Format 3: Weak Externals) Reviewed By: ruiu Differential Revision: https://reviews.llvm.org/D29892 This reapplies rL308329, which was reverted in rL308374 llvm-svn: 308379
* Revert r308329: llvm: add llvm-dlltool support to the archiverRui Ueyama2017-07-181-15/+7
| | | | | | This reverts commit r308329 because it broke buildbots. llvm-svn: 308374
* llvm: add llvm-dlltool support to the archiverMartell Malone2017-07-181-7/+15
| | | | | | | | | | | | | | | A PE COFF spec compliant import library generator. Intended to be used with mingw-w64. Supports: PE COFF spec (section 8, Import Library Format) PE COFF spec (Aux Format 3: Weak Externals) Reviewed By: ruiu Differential Revision: https://reviews.llvm.org/D29892 llvm-svn: 308329
* Re-land "COFF: migrate def parser from LLD to LLVM"Reid Kleckner2017-06-021-0/+319
| | | | | | | | | | | | | | | | | | | | | | This reverts commit r304561 and re-lands r303490 & co. The fix was to use "SymbolName" when translating LLD's internal export list to lib/Object's short export struct. The SymbolName reflects the actual symbol name, which may include fastcall and stdcall mangling bits not included in the /EXPORT or .def file EXPORTS name: @@ -434,8 +434,7 @@ std::vector<COFFShortExport> createCOFFShortExportFromConfig() { std::vector<COFFShortExport> Exports; for (Export &E1 : Config->Exports) { COFFShortExport E2; - E2.Name = E1.Name; + // Use SymbolName, which will have any stdcall or fastcall qualifiers. + E2.Name = E1.SymbolName; E2.ExtName = E1.ExtName; E2.Ordinal = E1.Ordinal; E2.Noname = E1.Noname; llvm-svn: 304573
* Revert "COFF: migrate def parser from LLD to LLVM"Reid Kleckner2017-06-021-319/+0
| | | | | | | | | | This reverts commits r303490, r303491, r303493, and r303494. This caused http://crbug.com/728726. Essentially, exporting stdcall functions doesn't appear to work after this change. Reduced test case soon. llvm-svn: 304561
* COFF: Fix another StringRef return errorMartell Malone2017-05-201-1/+1
| | | | | | | This should appease the lld build bot regression Following up on rL303493 llvm-svn: 303494
* COFF: migrate def parser from LLD to LLVM [1/2]Martell Malone2017-05-201-0/+319
This is split up into two commits. The will create the DEF parser in LLVM. Check the following commit to see the removal from LLD Reviewers: ruiu Differential Revision: https://reviews.llvm.org/D32689 llvm-svn: 303490
OpenPOWER on IntegriCloud