On 8 September 2014 23:06, Jonathan Roelofs <jonathan at codesourcery.com> wrote:>> I'm not sure we're on the same page... Your example, and the way that lit >> is currently set up, assumes BUILD and HOST are the same machine. > > or, at least, it assumes that lit is running on HOST.Isn't that the point? So lit can use "qemu-arm arm-linux-gnu-clang ...". Or are we going to run the lit inside the QEMU? I think this solution would be harder, as you'd need more context for python, etc. cheers, --renato
Sorry, this thread diverged a bit from the title, which I think may have confused things.... This started as a discussion of "how do we get libcxx's lit to run target executables inside qemu" and turned into "how can we make that generic enough to support actual hardware as the remote target", and further into "how about remote testing of the compiles too". Now as to your question, my intent is *not* to run arm-linux-gnu-clang inside qemu-arm on the x86 linux machine. And I also don't intend to run lit inside qemu. What I would like to do however, is something like this: For the moment, lets assume that I want to run my tests on real hardware, say a raspberry pi (I'll come back to how qemu ties into this in a bit). Suppose I have these three machines: role hostname triple BUILD tux i686-pc-linux-gnu HOST bob i386-pc-win32 TARGET pi armv6-unknown-linux-gnueabi and that I've built a canadian cross toolchain starting on 'tux', where users on machines like 'bob' build software targeting their raspberry pi's. I want to test both the i386-pc-win32-clang (which runs on 'bob'), as well as the executables that it produces (which run on 'pi'), but my testing infrastructure (i.e. python, LIT, etc) has to be on 'tux'. In this scenario, the run lines would have to be: // RUN: %host_run %clang %s -o %t && %target_run %t Where %host_run is some script that copies in %s and runs armv6-unknown-linux-gnueabi-clang on 'bob', and then copies out %t. And where %target_run is another script that copies in and runs %t on 'pi' And now, lets bring qemu back into the picture: now suppose my target hardware does not exist yet, so I've got to use qemu. I want to be able to test two versions of it: 1) one where qemu is built for 'tux' and 2) one where qemu is built for 'bob'. So now those scripts are as follows: 1) %host_run is the same as it was before. %target_run is a script that wraps qemu 2) %host_run is the same as it was before. %target_run is a script that copies %t over to 'bob', and runs %t inside qemu on 'bob'. TL;DR: I want to run LIT on one machine, clang on another, and the binaries that it produces on yet another machine (or even emulator). I hope that clarifies things a bit. Cheers, Jon -- View this message in context: http://llvm.1065342.n5.nabble.com/QEMU-testing-for-LIT-execution-tests-tp71755p72238.html Sent from the LLVM - Dev mailing list archive at Nabble.com.
Jon,> // RUN: %host_run %clang %s -o %t && %target_run %tlit has control over what it replaces %clang with, so no explicit %host_run is needed. In compiler-rt, for example, you might configure with: $ cmake -DCOMPILER_RT_TEST_COMPILER=my_clever_script.py That script would receive the path to the input and output files, which it could use to ssh to $HOST, compile and copy the output file back. Earlier I suggested using CMAKE_C_COMPILER. That could work too, but that variable is also used to compile libcxx - probably not what you want. -Greg On Mon, Sep 8, 2014 at 4:33 PM, jroelofs_ <jroelofs at gmail.com> wrote:> Sorry, this thread diverged a bit from the title, which I think may have > confused things.... > > This started as a discussion of "how do we get libcxx's lit to run target > executables inside qemu" and turned into "how can we make that generic > enough to support actual hardware as the remote target", and further into > "how about remote testing of the compiles too". > > Now as to your question, my intent is *not* to run arm-linux-gnu-clang > inside qemu-arm on the x86 linux machine. And I also don't intend to run lit > inside qemu. What I would like to do however, is something like this: > > For the moment, lets assume that I want to run my tests on real hardware, > say a raspberry pi (I'll come back to how qemu ties into this in a bit). > Suppose I have these three machines: > > role hostname triple > BUILD tux i686-pc-linux-gnu > HOST bob i386-pc-win32 > TARGET pi armv6-unknown-linux-gnueabi > > and that I've built a canadian cross toolchain starting on 'tux', where > users on machines like 'bob' build software targeting their raspberry pi's. > > I want to test both the i386-pc-win32-clang (which runs on 'bob'), as well > as the executables that it produces (which run on 'pi'), but my testing > infrastructure (i.e. python, LIT, etc) has to be on 'tux'. > > In this scenario, the run lines would have to be: > > // RUN: %host_run %clang %s -o %t && %target_run %t > > Where %host_run is some script that copies in %s and runs > armv6-unknown-linux-gnueabi-clang on 'bob', and then copies out %t. > And where %target_run is another script that copies in and runs %t on 'pi' > > And now, lets bring qemu back into the picture: now suppose my target > hardware does not exist yet, so I've got to use qemu. I want to be able to > test two versions of it: 1) one where qemu is built for 'tux' and 2) one > where qemu is built for 'bob'. So now those scripts are as follows: > > 1) > %host_run is the same as it was before. > %target_run is a script that wraps qemu > > 2) > %host_run is the same as it was before. > %target_run is a script that copies %t over to 'bob', and runs %t inside > qemu on 'bob'. > > TL;DR: I want to run LIT on one machine, clang on another, and the binaries > that it produces on yet another machine (or even emulator). > > > I hope that clarifies things a bit. > > > Cheers, > Jon > > > > -- > View this message in context: http://llvm.1065342.n5.nabble.com/QEMU-testing-for-LIT-execution-tests-tp71755p72238.html > Sent from the LLVM - Dev mailing list archive at Nabble.com. > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
On 9 September 2014 00:33, jroelofs_ <jroelofs at gmail.com> wrote:> role hostname triple > BUILD tux i686-pc-linux-gnu > HOST bob i386-pc-win32 > TARGET pi armv6-unknown-linux-gnueabi > > and that I've built a canadian cross toolchain starting on 'tux', where > users on machines like 'bob' build software targeting their raspberry pi's.Ah! Canadian cross... (*strokes moustache*).> TL;DR: I want to run LIT on one machine, clang on another, and the binaries > that it produces on yet another machine (or even emulator).Running QEMU, ssh etc. for lit tests is doable (I've done it before numerous times), but when I did it, I always wanted to, so the commands were hard-coded into the tests. I'm guessing that's what your %host_run and %target_run will do dynamically. It may be complicated, but doable. cheers, --renato