[Lldb-commits] [PATCH] D54914: Add a generic build script for building test inferiors

[Zachary Turner via Phabricator via lldb-commits]

zturner added a comment.

In D54914#1311137 <https://reviews.llvm.org/D54914#1311137>, @labath wrote:

> In D54914#1310337 <https://reviews.llvm.org/D54914#1310337>, @zturner wrote:
>
> > In D54914#1309700 <https://reviews.llvm.org/D54914#1309700>, @labath wrote:
> >
> > > I didn't look at the code in detail, as most of it deals with windows stuff, and I don't know much about those anyway. However, the interesting question for me would be how to make this useful for cross-compiling. Right now that sort of works for NativePDB tests because --compiler=clang-cl implies windows, but that won't help if I want to compile say a linux arm64 binary. I think that instead --arch, we should have a `--triple` argument, which specifies the exact target you want to build for. That can default to "host", and we can have special pseudo-triples like "host32" and "host64", if we want to be able to say "I want to build for a 32-bit flavour of the host arch". That could also make gcc detection easier, since you could just search for `$triple-gcc`.
> >
> >
> > A triple is one way.  I don't know much about gcc, does it support the same triple format as clang?
>
>
> Gcc is different that clang in that the target triple is baked into the binary. For example, on my machine, I have a binary called `x86_64-pc-linux-gnu-gcc` (`gcc` is just a symlink to that), which always produces binaries for x86_64 linux. If I had a arm64 cross-gcc installed, it would be called something like `aarch64-linux-gnu-gcc` and so on. So the actual mechanism to search for the compiler and invoke it will be different, but a triple is still a good starting point.
>
> > Also, are there any existing use cases for specifying a triple in the lit test suite?
>
> You can take a look at the tests in `lit/SymbolFile/DWARF`. Their purpose is very similar to the NativePDB tests -- check the operation of the dwarf parser, regardless of the host platform. Since mac uses a somewhat different flavour of dwarf than  other platforms, the sources are usually compiled twice, targetting linux and mac.
>
> >   I do agree we will need the ability to support triple specification, but it seems better to do this as a followup.  I don't think it should be too hard as long as we can make some assumptions such as "specification of --triple limits the possible supported compilers", etc.
>
> I don't think there needs to be much code initially, but I think it would be good to decide on the direction up front. For example, if we decide to go the triple way then we could avoid the churn in the tests by making all of them use `--triple=x86_64-pc-windows` instead of the current `--arch=64`, even if the actual implementation simply aborts in the more complicated cases.


I think it would be good to use the way dotest works as a starting point.  You can specify --arch, and then you can run the test on multiple arches this way by running dotest several times in succession, each with different arch flags.

I think a --triple option could be useful in limited scenarios, but I think that most of the use cases will not need it.  Most tests will probably want to specify nothing at all and let the lit configuration pass the correct information through.  Actually, I think this is the same with the --arch flag though.  Because as soon as you specify something, then it limits the ability of the test to run over and over with different parameters.

Perhaps we could support *both* a --triple and a --arch flag.  Maybe we can make the script error if they're both specified.  This would give each test the capability to be written in the simplest way possible.


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

https://reviews.llvm.org/D54914