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

[Blue Swirl <blauwirbel@gmail.com>]

On Fri, Jul 2, 2010 at 3:37 PM, Paolo Bonzini <pbonzini@redhat.com> wrote:
> 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.

FYI: SPARC/glibc is buggy, especially setjmp/longjmp which is critical to TCG.

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

We could also use Stefan's generic byte code interpreter for the
problematic hosts.