qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Aleksandar Markovic
Subject: Re: [Qemu-devel] tcg_register_jit_int() interface problem
Date: Mon, 16 Jul 2018 12:55:58 +0000

> From: Peter Maydell <address@hidden>
> Sent: Monday, July 16, 2018 1:55 PM
>
> On 16 July 2018 at 12:36, Aleksandar Markovic <address@hidden> wrote:
> >> From: Laurent Vivier <address@hidden>
> >> Le 16/07/2018 à 13:10, Aleksandar Markovic a écrit :
> >> > 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?
>
> The assumption has previously been that there must be a value known
> at compile time (because it would be the value of whatever is in the
> ELF header for the QEMU executable itself, effectively). I'm not
> sure why this doesn't work for MIPS still -- if you're building
> on a host with the new nanoMIPS stuff and with that support enabled,
> then report EM_NANOMIPS; if you're building a binary that works with
> the older MIPS CPUs, report EM_MIPS ?
>
> That said, if this doesn't work for MIPS, then it would be a trivial
> refactor to allow the tcg per-target code to do
> #define ELF_HOST_MACHINE mips_get_elf_host_machine()
> so you could compute the value at runtime.
>

Thanks for hints and suggestions. I will have to revisit the code and find the 
most suitable solution.

Ragards,
Aleksandar


reply via email to

[Prev in Thread] Current Thread [Next in Thread]