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

Tue Oct 15 11:35:56 PDT 2019

labath added a comment.

In D68980#1709884 <https://reviews.llvm.org/D68980#1709884>, @stella.stamenova wrote:

> The two things that come to mind are the path to clang-cl (which is sometimes a clang build and sometimes installed on the system as part of a VS installation or an LLVM installation) as well as the path to the linker when it is needed. This is most often an issue in the case of a VS install - I don't remember all the details any more, but I believe that before Zach added the script, we were often picking up the wrong clang-cl and ending up not being able to compile the tests at all.

Thanks.

Was this during a standalone lldb build? In a non-standalone build, lit should definitely prefer the just-built clang/lld (and if it doesn't, it should be fixed to do that). The situation is more complicated for a standalone build because the clang binary is sort of out of our control. But, in this case, I don't see how having build.py around can help, because the information about which clang to use has to come externally anyway...

In D68980#1709894 <https://reviews.llvm.org/D68980#1709894>, @amccarth wrote:

> My understanding is that the clang-cl driver does some poking around in the file system and registry to come up with defaults for the compatibility level, locations of the library and platform headers and such, but I believe that happens only if it needs to.  If all those answers are in the command line, it shouldn't bother inspecting the system.

Right, but the tests we are talking about here (e.g. SymbolFile/NativePDB/disassembly.cpp) should not need any of that registry stuff, should they?

The problem I have with this "workaround" is that it's unlikely to ever get fixed if it goes in, and I'd like to clarify the role of build.py in all this. E.g., if we are convinced that build.py needs to be used for all clang-cl invocations, then a more generic `--target` argument might be in order, so that one can later also use it to build arm-windows binaries (as they will likely have a similar problem).

Repository:
  rLLDB LLDB

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

https://reviews.llvm.org/D68980