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.