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

["Laurent Desnogues" <laurent.desnogues@gmail.com>]

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