aboutsummaryrefslogtreecommitdiff
path: root/llvm/lib/ToolDrivers
AgeCommit message (Collapse)AuthorFilesLines
2022-12-06Process: convert Optional to std::optionalKrzysztof Parzyszek1-1/+2
This applies to GetEnv and FindInEnvPath.
2022-12-02[llvm] Use std::nullopt instead of None (NFC)Kazu Hirata1-1/+1
This patch mechanically replaces None with std::nullopt where the compiler would warn if None were deprecated. The intent is to reduce the amount of manual work required in migrating from Optional to std::optional. This is part of an effort to migrate from llvm::Optional to std::optional: https://discourse.llvm.org/t/deprecating-llvm-optional-x-hasvalue-getvalue-getvalueor/63716
2022-07-21[llvm-lib] Ignore /VERBOSE flagPengxuan Zheng1-0/+1
Ignore the flag for now, but we can start using it for verbose output if needed. Reviewed By: thakis Differential Revision: https://reviews.llvm.org/D130202
2022-07-05[llvm-lib] Ignore /NODEFAULTLIB flagPengxuan Zheng1-0/+2
It doesn't look like there is anything llvm-lib needs to handle based on Microsoft's description of the flag. https://docs.microsoft.com/en-us/cpp/build/reference/managing-a-library?view=msvc-170 Reviewed By: thakis Differential Revision: https://reviews.llvm.org/D129032
2022-06-28[llvm-lib] Ignore /SUBSYSTEM flagPengxuan Zheng1-0/+1
It's not clear what Microsoft's LIB.exe actually does based on the official description of the flag (link below). We can probably ignore it for now. https://docs.microsoft.com/en-us/cpp/build/reference/managing-a-library?view=msvc-170 Reviewed By: thieta Differential Revision: https://reviews.llvm.org/D128458
2022-06-20[llvm] Don't use Optional::hasValue (NFC)Kazu Hirata1-1/+1
2022-05-27[llvm-lib] Ignore /LTCG optionPengxuan Zheng1-0/+1
"The /LTCG option to LIB specifies that the inputs from cl.exe include object files generated by using the /GL compiler option." Based on Microsoft's description above (https://docs.microsoft.com/en-us/cpp/build/reference/running-lib?view=msvc-170), there doesn't seem to be anything llvm-lib needs to do to support the flag. Reviewed By: rnk Differential Revision: https://reviews.llvm.org/D126000
2022-04-11[llvm-lib] Add /WX, warn by default on empty inputs, add opt-outNico Weber2-8/+32
lib.exe by default exits successfully without writing an output file when no inputs are passed. llvm-lib has the same behavior, for compatibility. This behavior interacts poorly with build systems: If a static library target had no inputs, llvm-lib would not produce an output file, causing ninja (or make, or a similar system) to successfully run that step, but then re-run it on the next build. After this patch, llvm-lib emits a warning in this case, that with /WX can be turned into an error. That way, ninja (or make, or...) will mark the initial build as failed. People who don't like the warning can use /ignore:emptyoutput to suppress it. The warning also points out the existing flag /llvmlibempty which forces creation of an empty .lib file (this is an extension to lib.exe). Differential Revision: https://reviews.llvm.org/D123517
2021-10-09[Type] Avoid APFloat.h include (NFC)Nikita Popov1-0/+1
This is only used by a handful of methods working on fltSemantics, and having these defined inline in the header does not look particularly important.
2021-06-24[OptTable] Rename PrintHelp to printHelpFangrui Song2-2/+2
To be consistent with other member functions and match the coding standard.
2021-06-25[llvm] Rename StringRef _lower() method calls to _insensitive()Martin Storsjö1-3/+3
This is a mechanical change. This actually also renames the similarly named methods in the SmallString class, however these methods don't seem to be used outside of the llvm subproject, so this doesn't break building of the rest of the monorepo.
2021-06-22[ADT] Add StringRef consume_front_lower and consume_back_lowerMartin Storsjö1-10/+3
These serve as a convenient combination of consume_front/back and startswith_lower/endswith_lower, consistent with other existing case insensitive methods named <operation>_lower. Differential Revision: https://reviews.llvm.org/D104218
2021-06-17[llvm-dlltool] Imply the target arch from a tool triple prefixMartin Storsjö1-11/+51
Also use the default LLVM target as default for dlltool. This matches how GNU dlltool behaves; it is compiled with one default target, which is used if no option is provided. Extend the anonymous namespace in the implementation file instead of using static functions. Based on a patch by Mateusz Mikuła. The effect of the default LLVM target, if neither the -m option nor a tool triple prefix is provided, isn't tested, as we can't make assumptions about what it is set to. (We could make the default be forced to one of the four supported architectures if the default triple is another arch, and then just test that llvm-dlltool without an -m option is able to produce an import library, without checking the actual architecture though.) Differential Revision: https://reviews.llvm.org/D104212
2021-03-25[NFC] Reordering parameters in getFile and getFileOrSTDINAbhina Sreeskantharajan1-4/+4
In future patches I will be setting the IsText parameter frequently so I will refactor the args to be in the following order. I have removed the FileSize parameter because it is never used. ``` static ErrorOr<std::unique_ptr<MemoryBuffer>> getFile(const Twine &Filename, bool IsText = false, bool RequiresNullTerminator = true, bool IsVolatile = false); static ErrorOr<std::unique_ptr<MemoryBuffer>> getFileOrSTDIN(const Twine &Filename, bool IsText = false, bool RequiresNullTerminator = true); static ErrorOr<std::unique_ptr<MB>> getFileAux(const Twine &Filename, uint64_t MapSize, uint64_t Offset, bool IsText, bool RequiresNullTerminator, bool IsVolatile); static ErrorOr<std::unique_ptr<WritableMemoryBuffer>> getFile(const Twine &Filename, bool IsVolatile = false); ``` Reviewed By: jhenderson Differential Revision: https://reviews.llvm.org/D99182
2021-01-26llvm-lib: Pull error printing code out of two functionsNico Weber1-22/+22
Slightly changes the output in error code, but no behavior change in normal use. This is for preparation for using these two functions elsewhere.
2020-11-13llvmbuildectomy - replace llvm-build by plain cmakeserge-sans-paille5-65/+12
No longer rely on an external tool to build the llvm component layout. Instead, leverage the existing `add_llvm_componentlibrary` cmake function and introduce `add_llvm_component_group` to accurately describe component behavior. These function store extra properties in the created targets. These properties are processed once all components are defined to resolve library dependencies and produce the header expected by llvm-config. Differential Revision: https://reviews.llvm.org/D90848
2020-07-24[llvm-lib] Support adding short import library objects with llvm-libMartin Storsjö1-2/+4
This fixes PR 42837. Differential Revision: https://reviews.llvm.org/D84465
2020-05-08[COFF] Use Expected in COFFObjectFile creationReid Kleckner1-4/+4
The constructor error out parameter was a bit awkward. Wrap it in a factory method which can return an error. Make the constructor private.
2020-05-01[ms] llvm-lib gives a more useful error if no inputs and no output path are ↵Eric Astor1-5/+10
provided Summary: If no inputs and no output path are provided, llvm-lib should produce a useful error. Before this, it would fail by reading from an unitialized StringRef. Reviewed By: vvereschaka Differential Revision: https://reviews.llvm.org/D79227
2020-04-30[ms] Add new option to llvm-lib: /llvmlibemptyEric Astor2-2/+6
Summary: Add a new option (/llvmlibempty). If passed and llvm-lib does not give an error, it will create a valid output archive even if empty. By default, llvm-lib mimicks lib.exe: if given no input files, it doesn't create its output file at all. This is incompatible with some build systems, so we add a command-line option to toggle this compatibility behavior. Reviewed By: thakis Differential Revision: https://reviews.llvm.org/D78894
2020-01-29[llvm] Replace SmallStr.str().str() with std::string conversion operator.Jonas Devlieghere1-1/+1
Use the std::string conversion operator introduced in d7049213d0fcda691c9e79f9b41e357198d99738.
2020-01-28Make llvm::StringRef to std::string conversions explicit.Benjamin Kramer2-2/+2
This is how it should've been and brings it more in line with std::string_view. There should be no functional change here. This is mostly mechanical from a custom clang-tidy check, with a lot of manual fixups. It uncovers a lot of minor inefficiencies. This doesn't actually modify StringRef yet, I'll do that in a follow-up.
2019-11-21[cmake] Explicitly mark libraries defined in lib/ as "Component Libraries"Tom Stellard2-2/+2
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
2019-10-02[llvm-lib] Detect duplicate input filesRui Ueyama1-0/+12
Differential Revision: https://reviews.llvm.org/D68320 llvm-svn: 373426
2019-10-02[llvm-lib] Correctly handle .lib input filesRui Ueyama1-88/+132
If archive files are passed as input files, llvm-lib needs to append the members of the input archive files to the output file. This patch implements that behavior. This patch splits an existing function into smaller functions. Effectively, the new code is only `if (Magic == file_magic::archive) { ... }` part. Fixes https://bugs.llvm.org/show_bug.cgi?id=32674 Differential Revision: https://reviews.llvm.org/D68204 llvm-svn: 373424
2019-09-02[llvm-dlltool] Handle external and internal names with differing decorationMartin Storsjo1-1/+12
Also add a missed part of the test from SVN r369747. Differential Revision: https://reviews.llvm.org/D66996 llvm-svn: 370656
2019-09-02[llvm-dlltool] Remove support for implying output nameMartin Storsjo1-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
2019-08-23[llvm-dlltool] Make sure to strip decorations from ExtName for renamed exportsMartin Storsjo1-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
2019-08-02[llvm-dlltool] Clarify an error message. NFC.Martin Storsjo1-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
2019-07-15[llvm-lib] Add a dependency to intrinsics_gen to the LLVMLibDriver buildStella Stamenova1-0/+3
Summary: Occasionally the build of LLVMLibDriver will fail because Attributes.inc has not been generated yet. Add an explicit dependency, so that we can guarantee that the file has been generated before LLVMLibDriver is build. ##[error]llvm\include\llvm\IR\Attributes.h(73,0): Error C1083: Cannot open include file: 'llvm/IR/Attributes.inc': No such file or directory llvm\include\llvm/IR/Attributes.h(73): fatal error C1083: Cannot open include file: 'llvm/IR/Attributes.inc': No such file or directory [LLVMLibDriver.vcxproj] Reviewers: asmith Subscribers: mgorny, hiraditya, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D64357 llvm-svn: 366097
2019-07-05lld, llvm-dlltool, llvm-lib: Use getAsString() instead of getSpelling() for ↵Nico Weber2-2/+4
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
2019-06-12Share /machine: handling code with llvm-cvtres tooNico Weber1-25/+1
r363016 let lld-link and llvm-lib share the /machine: parsing code. This lets llvm-cvtres share it as well. Making llvm-cvtres depend on llvm-lib seemed a bit strange (it doesn't need llvm-lib's dependencies on BinaryFormat and BitReader) and I couldn't find a good place to put this code. Since it's just a few lines, put it in lib/Object for now. Differential Revision: https://reviews.llvm.org/D63120 llvm-svn: 363144
2019-06-11llvm-lib: Implement /machine: argumentNico Weber2-10/+40
And share some code with lld-link. While here, also add a FIXME about PR42180 and merge r360150 to llvm-lib. Differential Revision: https://reviews.llvm.org/D63021 llvm-svn: 363016
2019-06-07llvm-lib: Disallow mixing object files with different machine typesNico Weber3-1/+87
lib.exe doesn't allow creating .lib files with object files that have differing machine types. Update llvm-lib to match. The motivation is to make it possible to infer the machine type of a .lib file in lld, so that it can warn when e.g. a 32-bit .lib file is passed to a 64-bit link (PR38965). Fixes PR38782. Differential Revision: https://reviews.llvm.org/D62913 llvm-svn: 362798
2019-06-04[llvm-ar] Reapply Fix relative thin archive path handlingOwen Reynolds1-3/+8
Includes a fix for an introduced build failure due to a post c++11 use of std::mismatch. This fixes some thin archive relative path issues, paths are shortened where possible and paths are output correctly when using the display table command. Differential Revision: https://reviews.llvm.org/D59491 llvm-svn: 362484
2019-06-03Revert "[llvm-ar] Fix relative thin archive path handling"Dmitri Gribenko1-8/+3
This reverts commit r362407. It broke compilation of llvm/lib/Object/ArchiveWriter.cpp: error: type 'llvm::sys::path::const_iterator' does not provide a call operator llvm-svn: 362413
2019-06-03[llvm-ar] Fix relative thin archive path handlingOwen Reynolds1-3/+8
This fixes some thin archive relative path issues, paths are shortened where possible and paths are output correctly when using the display table command. Differential Revision: https://reviews.llvm.org/D59491 llvm-svn: 362407
2019-02-13[llvm-ar][libObject] Fix relative paths when nesting thin archives.Jordan Rupprecht2-0/+14
Summary: When adding one thin archive to another, we currently chop off the relative path to the flattened members. For instance, when adding `foo/child.a` (which contains `x.txt`) to `parent.a`, when flattening it we should add it as `foo/x.txt` (which exists) instead of `x.txt` (which does not exist). As a note, this also undoes the `IsNew` parameter of handling relative paths in r288280. The unit test there still passes. This was reported as part of testing the kernel build with llvm-ar: https://patchwork.kernel.org/patch/10767545/ (see the second point). Reviewers: mstorsjo, pcc, ruiu, davide, david2050, inglorion Reviewed By: ruiu Subscribers: void, jdoerfert, tpimh, mgorny, hans, nickdesaulniers, hiraditya, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D57842 llvm-svn: 353995
2019-02-09llvm-lib: Implement /list flagNico Weber2-0/+49
Differential Revision: https://reviews.llvm.org/D57952 llvm-svn: 353620
2019-01-19Update the file headers across all of the LLVM projects in the monorepoChandler Carruth5-20/+15
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
2018-10-10[opt] Change the parameter of OptTable::PrintHelp from Name to Usage and ↵Fangrui Song2-2/+3
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
2018-07-14Give llvm-lib rudimentary help output.Nico Weber2-1/+11
https://reviews.llvm.org/D49318 llvm-svn: 337084
2018-05-09[COFF] Improve correctness of def parsing for GNU featuresMartin Storsjo1-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
2018-01-20[COFF] Keep the underscore on exported decorated stdcall functions in MSVC modeMartin Storsjo1-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
2017-12-13Remove redundant includes from various places.Michael Zolotukhin1-2/+0
llvm-svn: 320629
2017-10-23[COFF] Improve the check for functions that should get an extra underscoreMartin Storsjo1-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
2017-09-21Convert the archive writer to use Error.Rafael Espindola1-7/+7
This found one place in lld that was not checking the error. llvm-svn: 313937
2017-09-08[llvm-dlltool] Mention arm64 in the lists of architecture alternativesMartin Storsjo1-2/+2
This was missed in SVN r310223 when arm64 support was added. Differential Revision: https://reviews.llvm.org/D37588 llvm-svn: 312776
2017-09-06Removes redundant `llvm::`, add comments and simplify a return type of a ↵Rui Ueyama1-29/+32
function. No functional change intended. llvm-svn: 312673
2017-08-30Simplify writeArchive return type.Rui Ueyama1-6/+5
writeArchive returned a pair, but the first element of the pair is always its first argument on failure, so it doesn't make sense to return it from the function. This patch change the return type so that it does't return it. Differential Revision: https://reviews.llvm.org/D37313 llvm-svn: 312177
generated by cgit v1.1 at 2025-09-20 22:33:45 +0000