[Qemu-devel] Re: [PATCH 01/14] Add new data type for fprintf like function pointers

[Paolo Bonzini <pbonzini@redhat.com>]

On 04/09/2010 01:20 PM, Stefan Weil wrote:
> Some restrictions why qemu-common.h was not used might be no longer
> valid (I think they came from pre-tcg times). Nevertheless,
> cris-dis.c even says that it cannot include qemu-common.h (without
> giving a reason).

I think these are no longer valid.  In fact, almost everything is
including the full-blown qemu-common.h, via some other header file.

They may be valid only in cpu-exec.c and target-*/op_helper.c, but even
then maybe not. :)  In particular, I see two reasons to limit the number
of included files when global registers are in use.

The first is avoiding library calls since they may be unsafe some
OS/host combinations, particularly SPARC/glibc.  No includes -> no
prototypes -> no calls.  cpu-exec.c is careful to only use the global
env when it's safe to do so, but logging goes through fprintf and
target-*/op_helper.c files require logging.  Apparently, printf/fprintf
have been audited to work on SPARC/glibc too, so dyngen-exec.h allows
those calls.  This however does not *require* using custom declarations
in place of stdio.h as done in dyngen-exec.h, it's just a small safety net.

The second (more real) reason is inline assembly failures, for example
(32-bit x86):

     register int e asm("edi");

     static inline int h()
     {
         int x;
         asm volatile ("mov $0, %0" : "=D" (x));
     }

     int g()
     {
         int f = e;
         h();
         return e - f;
     }

fails to compile because gcc cannot assign edi to %0 in h().  Some host
headers may use assembly in a way that breaks qemu.  With only one
global register in use, however, it makes sense IMO to drop the custom
inclusion hacks and see if anyone screams.

Paolo