[all-commits] [llvm/llvm-project] 1ca4b5: [sanitizer][win] Change cmdline check to allow dou...

Tue Mar 28 00:00:10 PDT 2023

  Branch: refs/heads/release/16.x
  Home:   https://github.com/llvm/llvm-project
  Commit: 1ca4b5cfaa70c257772758cc188cf5a3a311b963
      https://github.com/llvm/llvm-project/commit/1ca4b5cfaa70c257772758cc188cf5a3a311b963
  Author: Alvin Wong <alvin at alvinhc.com>
  Date:   2023-03-28 (Tue, 28 Mar 2023)

  Changed paths:
    M compiler-rt/lib/sanitizer_common/sanitizer_symbolizer_win.cpp
    M compiler-rt/test/asan/TestCases/Windows/report_after_syminitialize.cpp

  Log Message:
  -----------
  [sanitizer][win] Change cmdline check to allow double backslashs

When `llvm-symbolizer.exe` is on the PATH in an entry containing two
consecutive backslashes, sanitizers will try to launch llvm-symbolizer
with its absolute path containing these consecutive backslashes. This
fails a sanity check in `sanitizer_symbolizer_win.cpp`.

According to the documentation of `CommandLineToArgvW` [1] and a MS blog
post [2], backslashes in general, regardless of how many of them in a
row, do not have any special effect, unless when immediately followed by
a double quote.

There already exists a check that fails when the command line arguments
contains double quote, therefore the check for double backslashes can
simply be removed.

[1]: https://learn.microsoft.com/en-us/windows/win32/api/shellapi/nf-shellapi-commandlinetoargvw
[2]: https://learn.microsoft.com/en-us/archive/blogs/twistylittlepassagesallalike/everyone-quotes-command-line-arguments-the-wrong-way

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

(cherry picked from commit b1871ceb1cf6c6954380867d41db3812e9e0dbfc)

  Commit: 8de1b29840b5d14e640ff5fecf8b9437e3556537
      https://github.com/llvm/llvm-project/commit/8de1b29840b5d14e640ff5fecf8b9437e3556537
  Author: Yi Kong <yikong at google.com>
  Date:   2023-03-28 (Tue, 28 Mar 2023)

  Changed paths:
    M llvm/tools/llvm-objdump/ObjdumpOpts.td

  Log Message:
  -----------
  [llvm-objdump] Fix help message for --print-imm-hex

Commit cc2457ca1bbd changed the default but forgot to update the help message.

(cherry picked from commit 3d65cd405d64afd86a59c1f58098dfe891841271)

  Commit: ebafcb86c35c00e9ef7c0af59401e395f89b2097
      https://github.com/llvm/llvm-project/commit/ebafcb86c35c00e9ef7c0af59401e395f89b2097
  Author: Martin Storsjö <martin at martin.st>
  Date:   2023-03-28 (Tue, 28 Mar 2023)

  Changed paths:
    M llvm/cmake/modules/AddLLVM.cmake

  Log Message:
  -----------
  [CMake] Respect variables for specifying host tools even without LLVM_USE_HOST_TOOLS set

When LLVM_NATIVE_TOOL_DIR was introduced in
d3da9067d143f3d4ce59b6d9ab4606a8ef1dc937 / D131052, it consisted
of refactoring a couple cases of manual logic for tools in
clang-tools-extra/clang-tidy, clang-tools-extra/pseudo/include
and mlir/tools/mlir-linalg-ods-gen. The former two had the same
consistent behaviour while the latter was slightly different, so
the refactoring would end up slightly adjusting one or the other.

The difference was that the clang-tools-extra tools respected the
external variable for setting the tool name, regardless of the
LLVM_USE_HOST_TOOLS variable, while mlir-linalg-ods-gen tool
only checked its external variable if LLVM_USE_HOST_TOOLS was set.

LLVM_USE_HOST_TOOLS is supposed to be enabled automatically whenever
cross compiling, so this shouldn't have been an issue.

In https://github.com/llvm/llvm-project/issues/60784, it seems like
some users do cross compile LLVM, without CMake knowing about it
(without CMAKE_CROSSCOMPILING being set). In these cases, their
build broke, as the variables for pointing to external host tools
no longer were being respected.

The fact that CMAKE_CROSSCOMPILING wasn't set stems from a
non-obvious behaviour of CMake; CMAKE_CROSSCOMPILING isn't supposed
to be set by the user (and if it was, it gets overridden), but one
has to set CMAKE_SYSTEM_NAME to indicate that one is cross compiling,
even if the target OS is the same as the current host.

Skip the checks for LLVM_USE_HOST_TOOLS and always respect the
variables for pointing to external tools (both the old tool specific
variables, and the new LLVM_NATIVE_TOOL_DIR), if they're set. This
makes the logic within setup_host_tool more exactly match the
logic for the clang-tools-extra tools from before the refactoring
in d3da9067d143f3d4ce59b6d9ab4606a8ef1dc937. This makes the behaviour
consistent with that of the tablegen executables, which also respect
the externally set variables regardless of LLVM_USE_HOST_TOOLS.

This fixes
https://github.com/llvm/llvm-project/issues/60784.

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

(cherry picked from commit 4a5bc791f38a5156bdba87a0572642b1bf3521e9)

Compare: https://github.com/llvm/llvm-project/compare/973cea755440...ebafcb86c35c