[Lldb-commits] [PATCH] D68980: [LLDB] [test] Pass --target=<arch>-windows-msvc to clang-cl

Tue Oct 15 05:06:34 PDT 2019

mstorsjo added a comment.

In D68980#1709314 <https://reviews.llvm.org/D68980#1709314>, @labath wrote:

> For the tests that "assume" that they are building for x86, how exactly do these assumptions of theirs manifest?

Two tests fail, SymbolFile/NativePDB/disassembly.cpp and SymbolFile/NativePDB/function-types-calling-conv.cpp.

disassembly.cpp fails at `disassemble --flavor=intel` since `--flavor=intel` doesn't make sense when disassembling an arm binary. But even if that would have succeeded, the test checks for specific disassembly in the output, so obviously this test assumes that the compiler defaults to x86_64 (so this test would fail on any 32 bit host platform as well).

function-types-calling-conv.cpp fails with the error "error in backend: target does not implement codeview register mapping". When running tests on an arm64 target, but building with `-m32`, it tries to build for arm-windows-msvc. This target is less feature complete than arm64, and e.g. codeview debug info isn't supported at all there. Furthermore, this test expects to inspect certain calling convention attributes, which only are valid on i386 (hence the `-m32` in the test, but it should really be `--arch i386` or similar).

There's other tests in this directory, which don't specify `-m32`, which on arm64 linux ends up building for arm64 windows (which is more complete than the arm32 windows target) and the tests do actually succeed, even though they probably do something else than what was intended. But if run on e.g. arm32 linux, many more of the tests (that don't specify any desired architecture) would end up with the less functional arm32 windows target.

> I assume these are tests that currently run on non win-x86 platforms too, or else you wouldn't have picked them up. Is that right? Would it be possible to rewrite these tests to call clang-cl directly?

I guess it should be possible to rewrite them that way, yes.

> In my ideal world, I'd have tests which do not need to produce a "functional" executable (but rather always create the same kind of target, regardless of what the host is), invoke the right compiler directly -- since the target/compiler is fixed, they can pass any funky option they like without needing to worry about portability. That would leave build.py with the task of figuring out how to build a binary that will run correctly on the host (possibly with a different bitness).
> 
> However, I don't know if that is really possible. I know there are some complexities with configuring msvc/clang-cl, where one needs to fetch registry keys and whatnot in order to get the right build environment. *However*, given that these tests don't always run on the host, they cannot assume that the registry keys will be there anyway, and so avoiding their lookup might actually be good, as it will ensure the tests will run the same way on regardless of the host environment.

At least these tests run with `--nodefaultlib` so they shouldn't actually need a full winsdk installation, and as they do run and succeed with this change, it should be possible to rewrite them to use clang-cl directly.

Repository:
  rLLDB LLDB

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D68980/new/

https://reviews.llvm.org/D68980