[Qemu-devel] tcg_register_jit_int() interface problem

[Qemu-devel] tcg_register_jit_int() interface problem

[Aleksandar Markovic]

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.)

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

[Laurent Vivier]

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

Thanks,
Laurent

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

[Aleksandar Markovic]

> From: Laurent Vivier <laurent@vivier.eu>
> 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

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

[Peter Maydell]

On 16 July 2018 at 12:36, Aleksandar Markovic <amarkovic@wavecomp.com> wrote:
>> From: Laurent Vivier <laurent@vivier.eu>
>> 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
-- PMM

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

[Aleksandar Markovic]

> From: Peter Maydell <peter.maydell@linaro.org>
> Sent: Monday, July 16, 2018 1:55 PM
>
> On 16 July 2018 at 12:36, Aleksandar Markovic <amarkovic@wavecomp.com> wrote:
> >> From: Laurent Vivier <laurent@vivier.eu>
> >> 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

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

[Laurent Vivier]

Le 16/07/2018 à 14:55, Aleksandar Markovic a écrit :
>> From: Peter Maydell <peter.maydell@linaro.org>
>> Sent: Monday, July 16, 2018 1:55 PM
>>  
>> On 16 July 2018 at 12:36, Aleksandar Markovic <amarkovic@wavecomp.com>
> wrote:
>> >> From: Laurent Vivier <laurent@vivier.eu>
>> >> 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

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

[Aleksandar Markovic]

> From: Laurent Vivier <laurent@vivier.eu>
> Sent: Monday, July 16, 2018 3:04 PM
>
> Does this mean an EM_NANOMIPS binary can be run on an EM_MIPS machine
> and vice-versa?

No, EM_NANOMIPS is meant to be run on EM_NANOMIPS only, and EM_MIPS on EM_MIPS only.

Regards,
Aleksandar

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

[Richard Henderson]

On 07/16/2018 06:23 AM, Aleksandar Markovic wrote:
> No, EM_NANOMIPS is meant to be run on EM_NANOMIPS only, and EM_MIPS on EM_MIPS
> only.

Exactly.  So why do you imagine a problem with separate binaries.

Recall -- this is not depending on *targeting* QEMU, but *hosting* QEMU.


r~

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

[Richard Henderson]

On 07/16/2018 04:36 AM, Aleksandar Markovic wrote:
> 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?

I really don't imagine how you would *not* have different executables.

NanoMIPS and MIPS III cannot be run on the same machine, surely?


r~