Patchwork [12/12] ARM: Add arm64 target to configure

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

Signed-off-by: Alexander Graf <agraf@suse.de>
---
 configure                |    9 +++++++++
 linux-user/Makefile.objs |    1 +
 2 files changed, 10 insertions(+), 0 deletions(-)

On 6 March 2013 10:01, Alexander Graf <agraf@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.

We may have to have a naming argument later but I want to think
my position through first :-)

> --- a/configure
> +++ b/configure
> @@ -3987,6 +3987,15 @@ case "$target_arch2" in
>      target_llong_alignment=4
>      target_libs_softmmu="$fdt_libs"
>    ;;
> +  arm64)
> +    TARGET_BASE_ARCH=arm
> +    TARGET_ABI_DIR=arm

Hmm. Shouldn't the ABI dir be different? After all, the ABI is...

> +    bflt="yes"

Really?

> diff --git a/linux-user/Makefile.objs b/linux-user/Makefile.objs
> index 5899d72..7a2cb94 100644
> --- a/linux-user/Makefile.objs
> +++ b/linux-user/Makefile.objs
> @@ -4,4 +4,5 @@ obj-y = main.o syscall.o strace.o mmap.o signal.o \
>  obj-$(TARGET_HAS_BFLT) += flatload.o
>  obj-$(TARGET_I386) += vm86.o
>  obj-$(TARGET_ARM) += arm/nwfpe/
> +obj-$(TARGET_ARM64) += arm/nwfpe/

I really don't want to drag the nwfpe FPA emulation code into
AArch64. It's pretty nearly obsolete for 32 bit ARM and it
definitely makes zero sense for 64 bit binaries.

-- PMM

On 6 March 2013 10:01, Alexander Graf <agraf@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