[Qemu-devel] dyngen-exec.h vs. qemu-common.h

[Qemu-devel] dyngen-exec.h vs. qemu-common.h

[Jan Kiszka]

[-- Attachment #1: Type: text/plain, Size: 817 bytes --]

Hi,

right now dyngen-exec.h prevents that qemu-common.h (or other headers
that drag in standard headers) can be included into all parts of qemu.
The reason for this is that dyngen-exec.h redefines a bunch of standard
types, and that is likely due to

[dyngen-exec.h:]
/* NOTE: standard headers should be used with special care at this
   point because host CPU registers are used as global variables. Some
   host headers do not allow that. */

Trying to add the noreturn definition to a central place, I wonder now
if that comment will still be valid when we only have TCG archs, i.e. if
the successor of dyngen-exec.h could possibly become compatible with
standard headers? Or what host headers on what host OS / distro are the
precise problem that could survive the dyngen era?

Thanks,
Jan


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 257 bytes --]

[Qemu-devel] Re: dyngen-exec.h vs. qemu-common.h

[Jan Kiszka]

[-- Attachment #1: Type: text/plain, Size: 912 bytes --]

Jan Kiszka wrote:
> Hi,
> 
> right now dyngen-exec.h prevents that qemu-common.h (or other headers
> that drag in standard headers) can be included into all parts of qemu.
> The reason for this is that dyngen-exec.h redefines a bunch of standard
> types, and that is likely due to
> 
> [dyngen-exec.h:]
> /* NOTE: standard headers should be used with special care at this
>    point because host CPU registers are used as global variables. Some
>    host headers do not allow that. */
> 
> Trying to add the noreturn definition to a central place, I wonder now
> if that comment will still be valid when we only have TCG archs, i.e. if
> the successor of dyngen-exec.h could possibly become compatible with
> standard headers? Or what host headers on what host OS / distro are the
> precise problem that could survive the dyngen era?
> 

Mmm, no one here who understands this code?

Jan


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 257 bytes --]

Re: [Qemu-devel] dyngen-exec.h vs. qemu-common.h

[Laurent Desnogues]

On Fri, Dec 5, 2008 at 9:45 AM, Jan Kiszka <jan.kiszka@web.de> wrote:
>
> right now dyngen-exec.h prevents that qemu-common.h (or other headers
> that drag in standard headers) can be included into all parts of qemu.
> The reason for this is that dyngen-exec.h redefines a bunch of standard
> types, and that is likely due to
>
> [dyngen-exec.h:]
> /* NOTE: standard headers should be used with special care at this
>   point because host CPU registers are used as global variables. Some
>   host headers do not allow that. */
>
> Trying to add the noreturn definition to a central place, I wonder now
> if that comment will still be valid when we only have TCG archs, i.e. if
> the successor of dyngen-exec.h could possibly become compatible with
> standard headers? Or what host headers on what host OS / distro are the
> precise problem that could survive the dyngen era?

Here is my understaning (to be taken with a grain of salt as I don't
know the dyngen era).

For dyngen some registers were globally allocated and great
care had to be taken where they are used so that they are not
used by included file (this can probably happen if you use some
standard header that inlines code).  The files where this matters
are the one containing execution loop (cpu-exec.c) and the
one containing helper runtime that use the global registers
(op_helper.c).

Basically once all op_helper.c files which still contain references
to global registers are removed then we should be safe and
we'll be able to get rid of hostregs_helper.h.

As an example here is what the situation is for the ARM target:

- three global registers are used
   * env is a global register that contains the address of the
     CPU state
   * T0 and T1 are two temporaries for parameter passing
     and result returning in op_helper

- in op_helper you can see that env, T0 and T1 are used
  (note that except for the 5 last helpers in that file, these
  helpers don't really have to be here, passing them the env
  as a parameter should be enough).

So if we want to get rid of dyngen-exec.h we have to remove
all references to global registers (and for the ARM target
that's not very difficult though a bit of a pain if you look at how
cpu_T0/T1 are used all over the place).  To look for what
needs to be done you can start by looking for uses of
tcg_global_reg_new*.

Note that, on top of my lack of knowledge of dyngen, I don't
know system emulation so I may have missed some bits.

HTH,

Laurent

[Qemu-devel] Re: dyngen-exec.h vs. qemu-common.h

[Jan Kiszka]

[-- Attachment #1: Type: text/plain, Size: 2829 bytes --]

Laurent Desnogues wrote:
> On Fri, Dec 5, 2008 at 9:45 AM, Jan Kiszka <jan.kiszka@web.de> wrote:
>> right now dyngen-exec.h prevents that qemu-common.h (or other headers
>> that drag in standard headers) can be included into all parts of qemu.
>> The reason for this is that dyngen-exec.h redefines a bunch of standard
>> types, and that is likely due to
>>
>> [dyngen-exec.h:]
>> /* NOTE: standard headers should be used with special care at this
>>   point because host CPU registers are used as global variables. Some
>>   host headers do not allow that. */
>>
>> Trying to add the noreturn definition to a central place, I wonder now
>> if that comment will still be valid when we only have TCG archs, i.e. if
>> the successor of dyngen-exec.h could possibly become compatible with
>> standard headers? Or what host headers on what host OS / distro are the
>> precise problem that could survive the dyngen era?
> 
> Here is my understaning (to be taken with a grain of salt as I don't
> know the dyngen era).
> 
> For dyngen some registers were globally allocated and great
> care had to be taken where they are used so that they are not
> used by included file (this can probably happen if you use some
> standard header that inlines code).  The files where this matters
> are the one containing execution loop (cpu-exec.c) and the
> one containing helper runtime that use the global registers
> (op_helper.c).
> 
> Basically once all op_helper.c files which still contain references
> to global registers are removed then we should be safe and
> we'll be able to get rid of hostregs_helper.h.
> 
> As an example here is what the situation is for the ARM target:
> 
> - three global registers are used
>    * env is a global register that contains the address of the
>      CPU state
>    * T0 and T1 are two temporaries for parameter passing
>      and result returning in op_helper
> 
> - in op_helper you can see that env, T0 and T1 are used
>   (note that except for the 5 last helpers in that file, these
>   helpers don't really have to be here, passing them the env
>   as a parameter should be enough).
> 
> So if we want to get rid of dyngen-exec.h we have to remove
> all references to global registers (and for the ARM target
> that's not very difficult though a bit of a pain if you look at how
> cpu_T0/T1 are used all over the place).  To look for what
> needs to be done you can start by looking for uses of
> tcg_global_reg_new*.
> 
> Note that, on top of my lack of knowledge of dyngen, I don't
> know system emulation so I may have missed some bits.
> 
> HTH,
> 
> Laurent

Yeah, thanks. That gives confidence that I can install a workaround to
cope with dyngen-exec.h dependencies for now and then look into
overcoming them finally.

Jan


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 257 bytes --]