Re: [Qemu-devel] tcg_register_jit_int() interface problem

[Aleksandar Markovic]

> From: Laurent Vivier <address@hidden>
> Sent: Monday, July 16, 2018 1:30 PM
>
> Le 16/07/2018 à 13:10, Aleksandar Markovic a écrit :
> > Hello, all.
> >
> >
> > Just a little background:
> >
> >
> > One of the fields in an ELF header is e_machine. It is meant to contain
> > "machine architecture". The numerical value is approved by a committee.
> > Some values for common targets are: EM_PPC, EM_PPC64, EM_ARM,
> > EM_AARCH64, etc.
> >
> >
> > The TCG function tcg_register_jit_int() expects that the preprocessor
> > constant ELF_HOST_MACHINE is defined, and uses internally the value of
> > that constant.
> >
> >
> > Consider, let's say, ARM: It definesELF_HOST_MACHINE in
> > tcg/arm/tcg-target.inc.c as
> >
> >
> > #define ELF_HOST_MACHINE EM_ARM
> >
> >
> > while in tcg/aarch64/tcg-target.inc.c it defines it as
> >
> >
> > #define ELF_HOST_MACHINE EM_AARCH64
> >
> >
> > For MIPS, the situation is different: Up until recently, MIPS had only
> > one value for e_machine: that was EM_MIPS (used for both 32-bit and
> > 64-bit MIPS systems). However, new nanoMIPS systems have a new value in
> > that field: EM_NANOMIPS (that is to be applied for both 32-bit and
> > 64-bit nanoMIPS systems).
> >
> >
> > The situation described above represent a problem for us developing
> > nanoMIPS support, forcing us to have different compilations (and
> > executables) for MIPS and nanoMIPS.
> >
> >
> > Is there a possibility to refactor tcg_register_jit_int() to receive
> > "e_machine" value as an argument, instead of expecting preprocessor
> > constant to be set?
>
> I don't know this par of code, but for PPC we have:
>
> #if TCG_TARGET_REG_BITS == 64
> # define ELF_HOST_MACHINE EM_PPC64
> #else
> # define ELF_HOST_MACHINE EM_PPC
> #endif
>
> So perhaps you could have something like:
>
> #if defined(HOST_NANOMIPS)
> # define ELF_HOST_MACHINE EM_NANOMIPS
> #else
> # define ELF_HOST_MACHINE EM_MIPS
> #endif

The problem is, this means there will be separate executables for QEMU for MIPS 
and QEMU for nanoMIPS. Would that be acceptable from overall QEMU design point 
of view? Peter, Richard?

Regards,
Aleksandar