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
