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

[Laurent Vivier]

Le 16/07/2018 à 14:55, Aleksandar Markovic a écrit :
>> 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.

Does this mean an EM_NANOMIPS binary can be run on an EM_MIPS machine
and vice-versa?

Thanks,
Laurent