[llvm-driver] Add a newline at the end of the help message (#99425)

This was constantly messing with my terminal prompt ��

[llvm-driver] Fix usage of `InitLLVM` on Windows (#76306)

Previously, some tools such as `clang` or `lld` which require strict
order for certain command-line options, such as `clang -cc1` or `lld

[llvm-driver] Fix usage of `InitLLVM` on Windows (#76306)

Previously, some tools such as `clang` or `lld` which require strict
order for certain command-line options, such as `clang -cc1` or `lld
-flavor`, would not longer work on Windows, when these tools were linked
as part of `llvm-driver`. This was caused by `InitLLVM` which was part
of the `*_main()` function of these tools, which in turn calls
`windows::GetCommandLineArguments`. That function completly replaces
argc/argv by new UTF-8 contents, so any ajustements to argc/argv made by
`llvm-driver` prior to calling these tools was reset.

`InitLLVM` is now called by the `llvm-driver`. Any tool that
participates in (or is part of) the `llvm-driver` doesn't call
`InitLLVM` anymore.

show more ...

Do not unnecessarily include StringSwitch.h

[llvm-driver] Allow llvm driver binary to be called anything

[llvm-driver] Reinvoke clang as described by llvm driver extra args

Differential Revision: https://reviews.llvm.org/D137800

[llvm-driver] Pass extra arguments to tools

Differential Revision: https://reviews.llvm.org/D137799

[llvm-driver] Just use argv[0]'s filename for finding tool

Usually we want the stem of argv[0] so something like clang-15
will correctly be identified as clang. For lld however, ld.lld
or ld-link wo

[llvm-driver] Just use argv[0]'s filename for finding tool

Usually we want the stem of argv[0] so something like clang-15
will correctly be identified as clang. For lld however, ld.lld
or ld-link would have a stem of just ld, so we also want to
use the full filename. The bug previously was that we were using
all of argv[0] so if you use a full path that happens to include a tool
name then that could be found first. This was the case in 2 stage
build where the binaries are stored in "tools/clang/stage2-bins/"
so some tools would end up as clang and not their intended tool.

show more ...

[llvm-driver] Add lld

The llvm-driver, enabled with LLVM_TOOL_LLVM_DRIVER_BUILD combines many llvm executables
into one to save overall toolchain size. This patch adds the capability for lld to be p

[llvm-driver] Add lld

The llvm-driver, enabled with LLVM_TOOL_LLVM_DRIVER_BUILD combines many llvm executables
into one to save overall toolchain size. This patch adds the capability for lld to be part of the
llvm-driver.

Differential Revision: https://reviews.llvm.org/D127472

show more ...

LLVM Driver Multicall tool

This patch adds an llvm-driver multicall tool that can combine multiple
LLVM-based tools. The build infrastructure is enabled for a tool by
adding the GENERATE_DRIVER opti

LLVM Driver Multicall tool

This patch adds an llvm-driver multicall tool that can combine multiple
LLVM-based tools. The build infrastructure is enabled for a tool by
adding the GENERATE_DRIVER option to the add_llvm_executable CMake
call, and changing the tool's main function to a canonicalized
tool_name_main format (i.e. llvm_ar_main, clang_main, etc...).

As currently implemented llvm-driver contains dsymutil, llvm-ar,
llvm-cxxfilt, llvm-objcopy, and clang (if clang is included in the
build).

llvm-driver can be enabled from builds by setting
LLVM_TOOL_LLVM_DRIVER_BUILD=On.

There are several limitations in the current implementation, which can
be addressed in subsequent patches:

(1) the multicall binary cannot currently properly handle
multi-dispatch tools. This means symlinking llvm-ranlib to llvm-driver
will not properly result in llvm-ar's main being called.
(2) the multicall binary cannot be comprised of tools containing
conflicting cl::opt options as the global cl::opt option list cannot
contain duplicates.

These limitations can be addressed in subsequent patches.

Differential revision: https://reviews.llvm.org/D109977

show more ...