From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from [140.186.70.92] (port=56964 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1P2qj4-0007xq-P9 for qemu-devel@nongnu.org; Mon, 04 Oct 2010 15:29:32 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1P2qj3-0007u2-0F for qemu-devel@nongnu.org; Mon, 04 Oct 2010 15:29:30 -0400 Received: from moutng.kundenserver.de ([212.227.126.187]:55018) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1P2qj2-0007tf-Jb for qemu-devel@nongnu.org; Mon, 04 Oct 2010 15:29:28 -0400 Message-ID: <4CAA2B13.304@mail.berlios.de> Date: Mon, 04 Oct 2010 21:29:23 +0200 From: Stefan Weil MIME-Version: 1.0 References: <1285270085-11276-1-git-send-email-weil@mail.berlios.de> <1285270085-11276-2-git-send-email-weil@mail.berlios.de> <4C9BBC2B.2030004@mail.berlios.de> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Subject: [Qemu-devel] [RFC] Can we remove special handling of standard headers (introduced for dyngen / OSX?) List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: QEMU Developers Cc: Blue Swirl Am 25.09.2010 09:46, schrieb Blue Swirl: > On Thu, Sep 23, 2010 at 8:44 PM, Stefan Weil wrote: >> Am 23.09.2010 22:33, schrieb Blue Swirl: >>> >>> On Thu, Sep 23, 2010 at 7:28 PM, Stefan Weil >>> wrote: >>>> >>>> Replace the remaining format attribute printf by macro >>>> GCC_FMT_ATTR which uses gnu_printf (if supported). >>>> >>>> This needs additional code changes: >>>> >>>> * Add qemu-common.h (which defined GCC_FMT_ATTR) were needed. >>>> >>>> * Remove standard includes when qemu-common.h was added. >>>> qemu-common.h already provides these includes. >>>> >>>> * Remove local definitions which now come from stdio.h. >>>> These definitions were needed before tcg was introduced. >>>> They raise conflicts when qemu-common.h is included. >>> >>> IIRC the problem was that some system headers were incompatible with >>> global asm variables. There is still one, AREG0. >>> >>> But I'd rather not keep the hideous local definitions forever. Maybe >>> those systems which are broken by the patch are not interesting >>> anymore? >> >> Are there such systems? Or did the problems with earlier >> versions arise from the fact that a lot of global asm variables >> were reserved by qemu? How could a correctly defined AREG0 >> interfere with system headers? > > One explanation is that the code in target-*/op_helper.c may assume > that env/AREG0 is always available but since library functions may > clobber that, we want to hide them. > >> For linux and win32, I did not notice problems caused by these changes. > > It looks like that code has origins in one of the very first patches, > r16 or ba1c6e37fc5efc0f3d1e50d0760f9f4a1061187b. It was moved from > exec-i386.h to dyngen-exec.h by r236 or > 79638566e5b87058e92f537b989df0dbc23f8b41. R997 or > 1e6cae953d6a37216359b79e05d23e1bf4dc6bbe added a warning about system > headers. The commits around that add OS X support, maybe the problem > was there? Current qemu code includes several locations where standard headers like stdio.h are forbidden. See qemu-common.h (__DYNGEN_EXEC_H__), dyngen-exec.h, cris-dis.h and perhaps more examples of this restriction. Who knows the reason for this restriction? Was it use of global registers with dyngen? Was it needed only for certain hosts (maybe OSX) or old versions of gcc? Most important: Is this restriction still needed? It would simplify things like common declarations and also allow cleaner code (without private declarations for FILE etc.) if we could remove this restriction. In my personal test environment (gcc-4.x, linux on different hosts, win32) the restriction was not needed. Regards, Stefan