From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from [140.186.70.92] (port=55498 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1OUxE2-0005gL-AN for qemu-devel@nongnu.org; Sat, 03 Jul 2010 03:33:25 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.69) (envelope-from ) id 1OUxE1-0006eZ-6c for qemu-devel@nongnu.org; Sat, 03 Jul 2010 03:33:22 -0400 Received: from mail-px0-f173.google.com ([209.85.212.173]:36098) by eggs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1OUxE1-0006eK-2E for qemu-devel@nongnu.org; Sat, 03 Jul 2010 03:33:21 -0400 Received: by pxi18 with SMTP id 18so371207pxi.4 for ; Sat, 03 Jul 2010 00:33:20 -0700 (PDT) MIME-Version: 1.0 In-Reply-To: <4C2E07B6.1050605@redhat.com> References: <1269890225-13639-1-git-send-email-weil@mail.berlios.de> <1269890225-13639-2-git-send-email-weil@mail.berlios.de> <20100408192902.GI6056@volta.aurel32.net> <4BBF0D7B.60400@mail.berlios.de> <4C2E07B6.1050605@redhat.com> From: Blue Swirl Date: Sat, 3 Jul 2010 07:32:59 +0000 Message-ID: Subject: Re: [Qemu-devel] Re: [PATCH 01/14] Add new data type for fprintf like function pointers Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Paolo Bonzini Cc: QEMU Developers , Aurelien Jarno On Fri, Jul 2, 2010 at 3:37 PM, Paolo Bonzini 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. =C2=A0In 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. :) =C2=A0In particular, I see two reasons to limit the nu= mber > 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. =C2=A0No includes -> no > prototypes -> no calls. =C2=A0cpu-exec.c is careful to only use the globa= l > env when it's safe to do so, but logging goes through fprintf and > target-*/op_helper.c files require logging. =C2=A0Apparently, printf/fpri= ntf > have been audited to work on SPARC/glibc too, so dyngen-exec.h allows > those calls. =C2=A0This however does not *require* using custom declarati= ons > in place of stdio.h as done in dyngen-exec.h, it's just a small safety ne= t. FYI: SPARC/glibc is buggy, especially setjmp/longjmp which is critical to T= CG. > The second (more real) reason is inline assembly failures, for example > (32-bit x86): > > =C2=A0 =C2=A0register int e asm("edi"); > > =C2=A0 =C2=A0static inline int h() > =C2=A0 =C2=A0{ > =C2=A0 =C2=A0 =C2=A0 =C2=A0int x; > =C2=A0 =C2=A0 =C2=A0 =C2=A0asm volatile ("mov $0, %0" : "=3DD" (x)); > =C2=A0 =C2=A0} > > =C2=A0 =C2=A0int g() > =C2=A0 =C2=A0{ > =C2=A0 =C2=A0 =C2=A0 =C2=A0int f =3D e; > =C2=A0 =C2=A0 =C2=A0 =C2=A0h(); > =C2=A0 =C2=A0 =C2=A0 =C2=A0return e - f; > =C2=A0 =C2=A0} > > fails to compile because gcc cannot assign edi to %0 in h(). =C2=A0Some h= ost > headers may use assembly in a way that breaks qemu. =C2=A0With 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.