From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from list by monty-python.gnu.org with tmda-scanned (Exim 4.24) id 1AcH63-0004P4-HS for qemu-devel@nongnu.org; Thu, 01 Jan 2004 23:39:39 -0500 Received: from mail by monty-python.gnu.org with spam-scanned (Exim 4.24) id 1AcH5R-0004AG-L2 for qemu-devel@nongnu.org; Thu, 01 Jan 2004 23:39:32 -0500 Received: from [62.210.158.41] (helo=moscou.magic.fr) by monty-python.gnu.org with esmtp (Exim 4.24) id 1AcH56-0003mO-Qx for qemu-devel@nongnu.org; Thu, 01 Jan 2004 23:38:40 -0500 Received: from 10.0.0.2 (ppp-181.net-555.magic.fr [62.210.255.181]) by moscou.magic.fr (8.11.6/8.10.1) with ESMTP id i023b4311959 for ; Fri, 2 Jan 2004 04:37:04 +0100 (CET) Subject: Re: [Qemu-devel] Segmentation fault with 0.50 and 0.51 and fedora core ls From: "J. Mayer" In-Reply-To: <1073011927.29451.5.camel@intrepid> References: <1073011927.29451.5.camel@intrepid> Content-Type: text/plain Message-Id: <1073013983.7385.9.camel@rapid> Mime-Version: 1.0 Date: Fri, 02 Jan 2004 04:26:23 +0100 Content-Transfer-Encoding: 7bit Reply-To: qemu-devel@nongnu.org List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: qemu-devel@nongnu.org On Fri, 2004-01-02 at 03:52, Michael Torrie wrote: > I'm still having many problems using qemu to run all but the most basic > static-ish x86 executables on my yellowdog ppc box. qemu just dies with > a segmentation fault. I can run xterm, xeyes, ddd, and adobe acrobat > reader, all from my x86 fedora core box (copying over the appropriate > libraries for glibc, x11, etc). However, most other exes, even a simple > exe like ls, fail with the segmentation fault. Since no one else is > reporting this problem on the list, I think that perhaps it is an > interaction between qemu and the ntpl-threaded glibc 2.3.3 that fedora > core ships with. You're right, this is the right explanation. I've already seen this problem, but didn't solve it, with a recent Debian using glibc 2.3... The glibc 2.3 signal context structure isn't the same that the one used in glibc 2.2. This makes qemu think that the emulated program is doing invalid access while it should detect some valid write access to code pages. I'm surprised that you were able to compile qemu with this glibc. When I tried to use glibc 2.3 on PPC, qemu failed to compile, because the structure field names also changed. Are your headers fully synchronised with your libc ? I don't believe it's a thread-scheme problem, because qemu don't use threads. Or it may be some other glibc definitions or structure padding or alignment which aren't the same than in the regular glibc... Regards. -- J. Mayer Never organized