On 6 March 2013 10:01, Alexander Graf <ag...@suse.de> wrote: > If we want to compile a target machine type that is AArch64 capable, > we need to add a new 64-bit capable ARM target. To make things easily > understandable, I call this arm64. That way we are > > 1) Compatible with Linux > 2) In line with the other targets in QEMU
OK, here goes the naming argument. Generally in QEMU we call the target name the same as the Linux reported architecture (ie what "uname -m" reports). For consistency with that approach we should thus be using "aarch64". (It's also what the gcc triplet uses.) I don't think there's much of a good argument for 'arm64' except personal aesthetic preference :-) > + arm64) > + TARGET_BASE_ARCH=arm > + TARGET_ABI_DIR=arm I think you shouldn't set TARGET_ABI_DIR here (which will cause us to go with the default of 'same as arch name', so linux-user/aarch64/). This will mean you can avoid having files like syscall_nr.h being of the form "#if 64 bits [huge long list] #else [huge long list] #endif" -- instead the two different ABIs just live in their own files in split directories. This is the way that qemu's x86, mips and sparc ports handle their 64 bit ABIs, and I think it makes sense. (I'd actually favour changing ppc to use a separate ppc64 directory whose foo.h header files did a #include "../ppc/foo.h" where the ABI is genuinely identical, and dropping ABI_DIR from configure entirely. That's a separate argument though.) (This will also work well with a potential refactoring of linux-user to put more files in the $abi_dir/ subdirectories rather than having #ifdefs in the top level files, but since that's only 'potential' it doesn't count for a huge amount.) thanks -- PMM