Re: [Qemu-devel] Re: [PATCH 01/14] Add new data type for fprintf like function pointers
On Fri, Jul 2, 2010 at 3:37 PM, Paolo Bonzini pbonz...@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.
[Qemu-devel] Re: [PATCH 01/14] Add new data type for fprintf like function pointers
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
