[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-devel] Re: [PATCH 01/14] Add new data type for fprintf like fu
From: |
Blue Swirl |
Subject: |
Re: [Qemu-devel] Re: [PATCH 01/14] Add new data type for fprintf like function pointers |
Date: |
Sat, 3 Jul 2010 07:32:59 +0000 |
On Fri, Jul 2, 2010 at 3:37 PM, Paolo Bonzini <address@hidden> 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.