qemu-devel
[Top][All Lists]
Advanced

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

[Qemu-devel] tcg_register_jit_int() interface problem


From: Aleksandar Markovic
Subject: [Qemu-devel] tcg_register_jit_int() interface problem
Date: Mon, 16 Jul 2018 11:10:54 +0000

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 defines ELF_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?


Please advice if you have something better in mind.


Yours,

Aleksandar


(cc. Laurent and Riku since this is also indirectly related to handling ELF 
headers linux user mode, and there will be a couple other nanoMIPS patches 
comming related to that.)




reply via email to

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