labath added a comment. 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. CHANGES SINCE LAST ACTION https://reviews.llvm.org/D54914/new/ https://reviews.llvm.org/D54914 _______________________________________________ lldb-commits mailing list lldb-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
