From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from [140.186.70.92] (port=36096 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1OUiJ1-000385-VI for qemu-devel@nongnu.org; Fri, 02 Jul 2010 11:37:33 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.69) (envelope-from ) id 1OUiJ0-0000ur-OV for qemu-devel@nongnu.org; Fri, 02 Jul 2010 11:37:31 -0400 Received: from mail-gy0-f173.google.com ([209.85.160.173]:38162) by eggs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1OUiJ0-0000ul-MC for qemu-devel@nongnu.org; Fri, 02 Jul 2010 11:37:30 -0400 Received: by gyf2 with SMTP id 2so956027gyf.4 for ; Fri, 02 Jul 2010 08:37:30 -0700 (PDT) Sender: Paolo Bonzini Message-ID: <4C2E07B6.1050605@redhat.com> Date: Fri, 02 Jul 2010 17:37:26 +0200 From: Paolo Bonzini MIME-Version: 1.0 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> In-Reply-To: <4BBF0D7B.60400@mail.berlios.de> Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: 7bit Subject: [Qemu-devel] Re: [PATCH 01/14] Add new data type for fprintf like function pointers List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Stefan Weil Cc: QEMU Developers , Aurelien Jarno 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