From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:52218) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TZ7lF-0006U9-Bu for qemu-devel@nongnu.org; Thu, 15 Nov 2012 17:18:16 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1TZ7lC-0003ob-9P for qemu-devel@nongnu.org; Thu, 15 Nov 2012 17:18:13 -0500 Received: from v220110690675601.yourvserver.net ([78.47.199.172]:38505) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TZ7lB-0003oW-Vd for qemu-devel@nongnu.org; Thu, 15 Nov 2012 17:18:10 -0500 Message-ID: <50A56A1F.30907@weilnetz.de> Date: Thu, 15 Nov 2012 23:18:07 +0100 From: Stefan Weil MIME-Version: 1.0 References: <1351697456-16107-1-git-send-email-pbonzini@redhat.com> <1351697456-16107-6-git-send-email-pbonzini@redhat.com> <50A52E14.2070106@weilnetz.de> <50A55615.1040003@redhat.com> In-Reply-To: <50A55615.1040003@redhat.com> Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [PATCH v2 05/39] fdsets: use weak aliases instead of qemu-tool.c/qemu-user.c List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Paolo Bonzini Cc: Blue Swirl , aliguori@us.ibm.com, qemu-devel@nongnu.org, stefanha@redhat.com Am 15.11.2012 21:52, schrieb Paolo Bonzini: > Il 15/11/2012 19:01, Stefan Weil ha scritto: >> Hi Paolo, >> >> this patch breaks QEMU on 32 and 64 bit hosts, native and with Wine. >> It's easy to reproduce the SIGSEGV crash: just add a -snapshot option. >> Obviously the critical code is executed only when this option was used. > > I cannot reproduce this, so it must be an assembler or linker bug. > > Can you try the alternative code that is used for Mac OS X? > > Paolo The code which is used for Mac OS X also compiles and results in the same run-time bug with Wine: wine: Unhandled page fault on write access to 0x00000004 at address 0x7b845d6e (thread 001b), starting debugger... (immediately after BIOS says "Booting from hard disk...") This was the modification used: diff --git a/compiler.h b/compiler.h index 55d7d74..62427e4 100644 --- a/compiler.h +++ b/compiler.h @@ -50,11 +50,12 @@ # define __printf__ __gnu_printf__ # endif # endif -# if defined(__APPLE__) +# if defined(__APPLE__) || defined(_WIN32) # define QEMU_WEAK_ALIAS(newname, oldname) \ static typeof(oldname) weak_##newname __attribute__((unused, weakref(#oldname))) # define QEMU_WEAK_REF(newname, oldname) (weak_##newname ? weak_##newname : oldname) # else +#error # define QEMU_WEAK_ALIAS(newname, oldname) \ typeof(oldname) newname __attribute__((weak, alias (#oldname))) # define QEMU_WEAK_REF(newname, oldname) newname These are my Debian packages (only the 32 bit ones are needed for the test): ii binutils-mingw-w64-i686 2.22-7+2 Cross-binutils for Win32 (x86) using MinGW-w64 ii binutils-mingw-w64-x86-64 2.22-7+2 Cross-binutils for Win64 (x64) using MinGW-w64 ii gcc-mingw-w64 4.6.3-8+7 GNU C compiler for MinGW-w64 ii gcc-mingw-w64-base 4.6.3-8+7 GNU Compiler Collection for MinGW-w64 (base package) ii gcc-mingw-w64-i686 4.6.3-8+7 GNU C compiler for MinGW-w64 targeting Win32 ii gcc-mingw-w64-x86-64 4.6.3-8+7 GNU C compiler for MinGW-w64 targeting Win64 ii mingw-w64 3.0~svn4933-1 Development environment targetting 32- and 64-bit Windows ii mingw-w64-dev 3.0~svn4933-1 Development files for MinGW-w64 ii mingw-w64-tools 3.0~svn4933-1 Development tools for 32- and 64-bit Windows On Windows, I used a rather new MinGW standard installation. I'll run more tests with other Linux distributions tomorrow. Cheers, Stefan >> Here is a simple command line using Wine: >> >> wine i386-softmmu/qemu-system-i386 -L pc-bios -snapshot Makefile >> >> The disk image does not matter, so I just selected QEMU's Makefile. >> >> It looks like weak symbols are not really working with MinGW >> (Blue Swirl previously pointed out that only ELF and a.out are >> officially supported). >> >> I can see in the debugger that QEMU wants to call monitor_fdset_dup_fd_find >> from qemu_close. >> >> In previous versions, this was just a dummy function returning 0. >> Now, it is the function in monitor.c, but the address does not match >> exactly, so the code addresses lines near the beginning of >> monitor_fdset_dup_fd_find which does not work of course. >> >> A trivial workaround is calling default_fdset_dup_fd_find which >> restores the old behaviour. I expect that all other weak functions >> would show the same problem if they were used. >> >> Regards, >> >> Stefan >> >> > >