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