summaryrefslogtreecommitdiffstats
path: root/llvm/lib/ToolDrivers/llvm-dlltool
Commit message (Collapse)AuthorAgeFilesLines
* [cmake] Explicitly mark libraries defined in lib/ as "Component Libraries"Tom Stellard2019-11-211-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: Most libraries are defined in the lib/ directory but there are also a few libraries defined in tools/ e.g. libLLVM, libLTO. I'm defining "Component Libraries" as libraries defined in lib/ that may be included in libLLVM.so. Explicitly marking the libraries in lib/ as component libraries allows us to remove some fragile checks that attempt to differentiate between lib/ libraries and tools/ libraires: 1. In tools/llvm-shlib, because llvm_map_components_to_libnames(LIB_NAMES "all") returned a list of all libraries defined in the whole project, there was custom code needed to filter out libraries defined in tools/, none of which should be included in libLLVM.so. This code assumed that any library defined as static was from lib/ and everything else should be excluded. With this change, llvm_map_components_to_libnames(LIB_NAMES, "all") only returns libraries that have been added to the LLVM_COMPONENT_LIBS global cmake property, so this custom filtering logic can be removed. Doing this also fixes the build with BUILD_SHARED_LIBS=ON and LLVM_BUILD_LLVM_DYLIB=ON. 2. There was some code in llvm_add_library that assumed that libraries defined in lib/ would not have LLVM_LINK_COMPONENTS or ARG_LINK_COMPONENTS set. This is only true because libraries defined lib lib/ use LLVMBuild.txt and don't set these values. This code has been fixed now to check if the library has been explicitly marked as a component library, which should now make it easier to remove LLVMBuild at some point in the future. I have tested this patch on Windows, MacOS and Linux with release builds and the following combinations of CMake options: - "" (No options) - -DLLVM_BUILD_LLVM_DYLIB=ON - -DLLVM_LINK_LLVM_DYLIB=ON - -DBUILD_SHARED_LIBS=ON - -DBUILD_SHARED_LIBS=ON -DLLVM_BUILD_LLVM_DYLIB=ON - -DBUILD_SHARED_LIBS=ON -DLLVM_LINK_LLVM_DYLIB=ON Reviewers: beanz, smeenai, compnerd, phosek Reviewed By: beanz Subscribers: wuzish, jholewinski, arsenm, dschuff, jyknight, dylanmckay, sdardis, nemanjai, jvesely, nhaehnle, mgorny, mehdi_amini, sbc100, jgravelle-google, hiraditya, aheejin, fedor.sergeev, asb, rbar, johnrusso, simoncook, apazos, sabuasal, niosHD, jrtc27, MaskRay, zzheng, edward-jones, atanasyan, steven_wu, rogfer01, MartinMosbeck, brucehoult, the_o, dexonsmith, PkmX, jocewei, jsji, dang, Jim, lenary, s.egerton, pzheng, sameer.abuasal, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D70179
* [llvm-dlltool] Handle external and internal names with differing decorationMartin Storsjo2019-09-021-1/+12
| | | | | | | | Also add a missed part of the test from SVN r369747. Differential Revision: https://reviews.llvm.org/D66996 llvm-svn: 370656
* [llvm-dlltool] Remove support for implying output nameMartin Storsjo2019-09-021-10/+2
| | | | | | | | | | I don't see GNU dlltool supporting doing this; with only a -d option and no -l option, GNU dlltool runs successfully but doesn't write any output file. Differential Revision: https://reviews.llvm.org/D65645 llvm-svn: 370655
* [llvm-dlltool] Make sure to strip decorations from ExtName for renamed exportsMartin Storsjo2019-08-231-0/+1
| | | | | | | | | | | | ExtName should not be decorated, just like Name. This avoids double decoration on symbols in import libraries that use = for renaming functions. (Weak aliases, which use ==, worked fine with respect to decoration.) Differential Revision: https://reviews.llvm.org/D66617 llvm-svn: 369747
* [llvm-dlltool] Clarify an error message. NFC.Martin Storsjo2019-08-021-1/+1
| | | | | | | | | | The parameter to the -D (--dllname) option is the name of the dll that llvm-dlltool produces an import library for. Even though this is named "OutputFile" in the COFFModuleDefinition class, it's not an output file name in the context of llvm-dlltool, but the name of the DLL to create an import library for. llvm-svn: 367676
* lld, llvm-dlltool, llvm-lib: Use getAsString() instead of getSpelling() for ↵Nico Weber2019-07-051-1/+2
| | | | | | | | | | | | | | | printing unknown args Since OPT_UNKNOWN args never have any values and consist only of spelling (and are never aliased), this doesn't make any difference in practice, but it's more consistent with Arg's guidance to use getAsString() for diagnostics, and it matches what clang does. Also tweak two tests to use an unknown option that contains '=' for additional coverage while here. (The new tests pass fine with the old code too though.) llvm-svn: 365200
* Update the file headers across all of the LLVM projects in the monorepoChandler Carruth2019-01-192-8/+6
| | | | | | | | | | | | | | | | | 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
* [opt] Change the parameter of OptTable::PrintHelp from Name to Usage and ↵Fangrui Song2018-10-101-1/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | don't append "[options] <inputs>" Summary: Before, "[options] <inputs>" is unconditionally appended to the `Name` parameter. It is more flexible to change its semantic to `Usage` and let user customize the usage line. % llvm-objcopy ... USAGE: llvm-objcopy <input> [ <output> ] [options] <inputs> With this patch: % llvm-objcopy ... USAGE: llvm-objcopy input [output] Reviewers: rupprecht, alexshap, jhenderson Reviewed By: rupprecht Subscribers: jakehehrlich, mehdi_amini, steven_wu, dexonsmith, llvm-commits Differential Revision: https://reviews.llvm.org/D51009 llvm-svn: 344097
* [COFF] Improve correctness of def parsing for GNU featuresMartin Storsjo2018-05-091-2/+2
| | | | | | | | | | | | | | | | | | | | | | | | 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] Keep the underscore on exported decorated stdcall functions in MSVC modeMartin Storsjo2018-01-201-1/+1
| | | | | | | | | This (together with the corresponding LLD commit, that contains the testcase updates) fixes PR35733. Differential Revision: https://reviews.llvm.org/D41631 llvm-svn: 323035
* Remove redundant includes from various places.Michael Zolotukhin2017-12-131-2/+0
| | | | llvm-svn: 320629
* [COFF] Improve the check for functions that should get an extra underscoreMartin Storsjo2017-10-231-2/+3
| | | | | | | | | | | 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] Mention arm64 in the lists of architecture alternativesMartin Storsjo2017-09-081-2/+2
| | | | | | | | This was missed in SVN r310223 when arm64 support was added. Differential Revision: https://reviews.llvm.org/D37588 llvm-svn: 312776
* NFC: fix ToolDrivers syntax and typo errorsMartell Malone2017-08-231-2/+2
| | | | | | | infoTable -> InfoTable camelCase Libtool Options #define offset llvm-svn: 311517
* [dlltool] Make memory buffer ownership less weird.Benjamin Kramer2017-08-201-10/+6
| | | | | | There's no reason to destroy them in a global destructor. llvm-svn: 311287
* [llvm-dlltool] Improve an error message when unable to open files. NFC.Martin Storsjo2017-08-171-1/+1
| | | | | | Differential Revision: https://reviews.llvm.org/D36818 llvm-svn: 311069
* [llvm-dlltool] Don't crash if no def file is provided or it can't be openedMartin Storsjo2017-08-171-7/+14
| | | | | | Differential Revision: https://reviews.llvm.org/D36780 llvm-svn: 311068
* [COFF] Make the weak aliases optionalMartin Storsjo2017-08-161-1/+1
| | | | | | | | | | | | | | | | When creating an import library from lld, the cases with Name != ExtName shouldn't end up as a weak alias, but as a real export of the new name, which is what actually is exported from the DLL. This restores the behaviour of renamed exports to what it was in 4.0. The other half of this commit, including test, goes into lld. Differential Revision: https://reviews.llvm.org/D36633 llvm-svn: 310991
* [llvm-dlltool] Fix creating stdcall/fastcall import libraries for i386Martin Storsjo2017-08-162-3/+19
| | | | | | | | | | | | | | | | | | | | | 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
* [llvm-dlltool] Map the "arm64" machine typeMartin Storsjo2017-08-061-0/+1
| | | | | | Differential Revision: https://reviews.llvm.org/D36365 llvm-svn: 310223
* llvm: add llvm-dlltool support to the archiverMartell Malone2017-07-184-0/+217
| | | | | | | | | | | | | | | | 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-184-217/+0
| | | | | | This reverts commit r308329 because it broke buildbots. llvm-svn: 308374
* llvm: add llvm-dlltool support to the archiverMartell Malone2017-07-184-0/+217
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
OpenPOWER on IntegriCloud