We have a modified version of projects/test-suite that we can run cross using Qemu. We would like to put that back so that other people can test MIPS before putting back. Well, this would be easily modifiable for ARM and other targets that are supported by QEMU. But in this case, we would need to check in a version of QEMU and also the needed pieces of a MIPS tool chain for assembly, linking, etc. Any thoughts on this? Over the weekend a change in LLVM by someone other than MIPS seems to have regressed our C++ big time. We are investigating. But the point is that these execution tests for cross compilers would be every helpful. We are very close to having MIPS native linux compilers that can function just like clang for x86 linux and others but this cross compiler testing is still very useful. Reed
On Mon, Nov 7, 2011 at 2:11 PM, reed kotler <rkotler at mips.com> wrote:> We have a modified version of projects/test-suite that we can run cross > using Qemu. > > We would like to put that back so that other people can test MIPS > before putting back. > Well, this would be easily modifiable for ARM and other targets that are > supported by QEMU. > > But in this case, we would need to check in a version of QEMU and also > the needed pieces of a MIPS tool chain for assembly, linking, etc. > > Any thoughts on this?If you need changes to RunSafely.sh etc. to tell the scripts to use application-level emulation via qemu, in addition to the existing options, that seems fine. We aren't going to put QEMU or binutils into the LLVM repository, though. If you want to make sure people don't break MIPS, I would suggest setting up a buildbot running the test-suite continuously. -Eli
Reed, On Nov 7, 2011, at 2:11 PM, reed kotler wrote:> We have a modified version of projects/test-suite that we can run cross > using Qemu. > > We would like to put that back so that other people can test MIPS > before putting back. > Well, this would be easily modifiable for ARM and other targets that are > supported by QEMU. > > But in this case, we would need to check in a version of QEMU and also > the needed pieces of a MIPS tool chain for assembly, linking, etc. > > Any thoughts on this?Why do you need changes to the scripts to make this work? The makefiles already support the $RUNUNDER option that we use to run tests under valgrind, which should be useable for qemu as well, perhaps with a shell script wrapper to get the arguments in the right format. --Owen
On 11/07/2011 02:38 PM, Owen Anderson wrote:> Reed, > > On Nov 7, 2011, at 2:11 PM, reed kotler wrote: > >> We have a modified version of projects/test-suite that we can run cross >> using Qemu. >> >> We would like to put that back so that other people can test MIPS >> before putting back. >> Well, this would be easily modifiable for ARM and other targets that are >> supported by QEMU. >> >> But in this case, we would need to check in a version of QEMU and also >> the needed pieces of a MIPS tool chain for assembly, linking, etc. >> >> Any thoughts on this? > Why do you need changes to the scripts to make this work? The makefiles already support the $RUNUNDER option that we use to run tests under valgrind, which should be useable for qemu as well, perhaps with a shell script wrapper to get the arguments in the right format. > > --OwenWe also need some MIPS toolchains but we can make a buildslave for this too. We will look into that.
On 11/07/2011 02:29 PM, Eli Friedman wrote:> On Mon, Nov 7, 2011 at 2:11 PM, reed kotler<rkotler at mips.com> wrote: >> We have a modified version of projects/test-suite that we can run cross >> using Qemu. >> >> We would like to put that back so that other people can test MIPS >> before putting back. >> Well, this would be easily modifiable for ARM and other targets that are >> supported by QEMU. >> >> But in this case, we would need to check in a version of QEMU and also >> the needed pieces of a MIPS tool chain for assembly, linking, etc. >> >> Any thoughts on this? > If you need changes to RunSafely.sh etc. to tell the scripts to use > application-level emulation via qemu, in addition to the existing > options, that seems fine. We aren't going to put QEMU or binutils > into the LLVM repository, though. If you want to make sure people > don't break MIPS, I would suggest setting up a buildbot running the > test-suite continuously. > > -EliWe have a build bot running nightly against LLVM tip of tree but when they break something, how do they figure out what they did? They need to be able to run what we ran.