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

[Martin Storsjö via Phabricator via lldb-commits]

mstorsjo added a comment.

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

> In D68980#1709967 <https://reviews.llvm.org/D68980#1709967>, @mstorsjo wrote:
>
> > In D68980#1709931 <https://reviews.llvm.org/D68980#1709931>, @labath wrote:
> >
> > > 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...
> >
> >
> > How do tests like test/Shell/Register/x86*.test work in such standalone builds then? They use lines like these:
> >
> >   # XFAIL: system-windows
> >   # REQUIRES: native && target-x86_64
> >   # RUN: %clangxx -fomit-frame-pointer %p/Inputs/x86-64-gp-read.cpp -o %t
> >   # RUN: %lldb -b -s %s %t | FileCheck %s
> >
> >
> > (The XFAIL for system-windows, at least in this test, when I tried it out, seemed to relate to the fact that `register read --all` on windows didn't include all the 32 bit subregisters.)
> >
> > If tests already can use such constrcuts, I don't see why we couldn't use `# RUN: %clang_cl ..`, as lit sets up `%clang_cl` in the same way as `%clangxx`.
>
>
> %clang_cl is where we started before we had build.py. It was over a year ago, so it's possible things have improved.


Possible, but I'm getting the feeling that there's cases that at least I'm overlooking, so I think it might be safer to just add a `--target` option to build.py. Or maybe make it accept an actual architecture name to `--arch`, in addition to 32/64/host? For non-clang-cl cases, it should only allow 32/64/host, but for clang-cl it could accept e.g. `i386`. How does that sound to you?


Repository:
  rLLDB LLDB

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

https://reviews.llvm.org/D68980