From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1IXm10-00024l-NX for qemu-devel@nongnu.org; Tue, 18 Sep 2007 18:57:58 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1IXm0z-00023r-Sh for qemu-devel@nongnu.org; Tue, 18 Sep 2007 18:57:58 -0400 Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1IXm0z-00023d-MB for qemu-devel@nongnu.org; Tue, 18 Sep 2007 18:57:57 -0400 Received: from mx2.suse.de ([195.135.220.15]) by monty-python.gnu.org with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.60) (envelope-from ) id 1IXm0z-0001l7-7C for qemu-devel@nongnu.org; Tue, 18 Sep 2007 18:57:57 -0400 In-Reply-To: <1190155304.14938.286.camel@rapid> References: <1190118724.9564.49.camel@phantasm.home.enterpriseandprosperity.com> <46EFD842.7070207@gmail.com> <1190139947.9564.60.camel@phantasm.home.enterpriseandprosperity.com> <1190152163.9564.81.camel@phantasm.home.enterpriseandprosperity.com> <1190155304.14938.286.camel@rapid> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <2A7DAB9C-352D-4069-B504-8FBCB30C8A8F@suse.de> Content-Transfer-Encoding: 7bit From: Alexander Graf Subject: Re: [Qemu-devel] Insta-segfault! i386-linux-user Date: Wed, 19 Sep 2007 00:57:49 +0200 Reply-To: qemu-devel@nongnu.org List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: qemu-devel@nongnu.org Cc: "J. Mayer" , thayne@c2.net On Sep 19, 2007, at 12:41 AM, J. Mayer wrote: > On Wed, 2007-09-19 at 00:07 +0200, Alexander Graf wrote: >> On Sep 18, 2007, at 11:49 PM, Thayne Harbaugh wrote: >> >>> On Tue, 2007-09-18 at 21:11 +0200, Alexander Graf wrote: >>>> On Sep 18, 2007, at 8:25 PM, Thayne Harbaugh wrote: >>>> >>>>> On Tue, 2007-09-18 at 15:53 +0200, Ronald wrote: >>>>>> Thayne Harbaugh schreef: >>> >>> >>> >>>>>>> ./i386-linux-user/qemu-i386 --help >>>>>>> Segmentation fault >>>>>>> >>>>>>>> From GDB: >>>>>>> >>>>>>> Program received signal SIGSEGV, Segmentation fault. >>>>>>> 0x0000000000000000 in ?? () >>>>>>> (gdb) bt >>>>>>> #0 0x0000000000000000 in ?? () >>>>>>> #1 0x00000000600575ed in __libc_csu_init () >>>>>>> #2 0x00002b826c660ade in __libc_start_main () from /lib/ >>>>>>> libc.so.6 >>>>>>> #3 0x00000000600050e9 in _start () >>> >>> >>> >>>> >>>> We had this on the list some months ago. >>> >>> I'll dig for that. >>> >>>> As far as I recall this >>>> correctly the problem is the linker script. Just take a look at the >>>> suse source rpm where we replace that one, so it works with x86_64. >>> >>> Thanks for the guidance. >>> >>>> Be prepared for breakage though, as linux-user on 64-Bit hosts does >>>> not work properly. >>> >>> What about it doesn't work properly? Do you have some links for the >>> list archives? >> >> Mostly syscalls that return 64-bit pointers. So for example mmap is >> broken. You can find a patch for x86_64 for that in the rpm or on the >> list as well, which does not fix the issue on ppc64 or ia64 though. > > As far of what I see in the code and I can see when executing programs > in linux-user on x86_64, mmap may be the safer 64 bits call... There > seem to be a hack for alpha, sparc, x86_64, ia64 and mips (don't know > why ppc64 is not in the list...) that force the requested address > to be > in the 32 bits address space (but does not seem to force the MAP_FIXED > flag...). On x86_64 there is a flags for mmap that forces it to only use 32 bits. That one is way easier but does not exist on other architectures. > >> Additionally there is an IPC call that does an mmap in the end, where >> you can not force it to return 32-bit values, so this can not be >> easily fixed. The IA64-IA32 emulator actually does have an approach >> for this, but I did not have the time to take a deeper look into >> that. > > Well, I noticed that there seem to be numerous problems in IPC, not > especially related to 64 bits. > As I reported yesterday, there seem to be some confusions between > short/int and long types for all the targets I checked. There also > seem > to be 64 bits issues, in addition... > I can see no mmap in IPC calls, but I noticed there is a problem for > 32/64 bits compatibility with the shmat call. I guess this can be > fixed > exactly in the same way mmap was fixed, forcing the requested > address to > a known area when the caller does not specify any... > This is what the IA64 emulator does and which is broken in qemu. Some months ago I sent some example programs to trigger this bug which actually only occured when I used threading. Just take a look at do_shmat in the ipc/shm.c in the linux kernel. The MAP_FIXED flag should work here, but the MAP_32BIT one is not available. I really don't remember which exact part broke, but I switched to using a 32- bit host for linux-user then and everything magically worked. Cheers, Alex