Le 16/07/2018 à 14:55, Aleksandar Markovic a écrit : >> From: Peter Maydell <[email protected]> >> Sent: Monday, July 16, 2018 1:55 PM >> >> On 16 July 2018 at 12:36, Aleksandar Markovic <[email protected]> > wrote: >> >> From: Laurent Vivier <[email protected]> >> >> 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
