On Wed, 23 Sep 2009, Steve Reinhardt wrote: > Endianness is a huge pain indeed. Does qemu actually do system call > emulation? I thought it just did full-system emulation (like our FS > mode).
It also has something called "linux-user" mode which is analagous to the m5 SE mode. It handles cross-endian issues and cross-bitsize issues mostly correctly. As you can imagine there are a lot of corner cases, especially when trying to deal with things like translating simulated 32-bit mmap() calls into host 64-bit mmap() calls (mmap on x86-64 likes to return pointers that are above 2^32, which obviously you can't pass back to a simulated 32-bit program). It works well enough that pretty much all of spec2k and spec2006 in SE mode work for MIPS (big endian), SPARC, X86, and X86_64 when running on x86_64. On Alpha the integer ones work, FP is a work in progress. Syscall support is good enough that I think some people even do ARM development by running an arm-qemu-linux-user bash on an x86 system, chroot to the root directory of an ARM filesystem, and just run the ARM executables as if they were native. The main hurdle left is trying to handle all the weird new Linux threading syscalls properly. > Unfortunately, even if qemu does have it all figured out, since it's > gpl (last time I looked) we can't steal their code without > compromising our bsd license which is not something we'd consider. yes, that's a shame. It's unfortunate always re-inventing the wheel. m5 is at least the 4th simulator on which I've spent a lot of time tracking down system call problems. Vince _______________________________________________ m5-dev mailing list [email protected] http://m5sim.org/mailman/listinfo/m5-dev
