qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] Insta-segfault! i386-linux-user


From: J. Mayer
Subject: Re: [Qemu-devel] Insta-segfault! i386-linux-user
Date: Wed, 19 Sep 2007 00:41:44 +0200

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:
> >
> > <SNIP>
> >
> >>>>> ./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 ()
> >
> > <SNIP>
> >
> >>
> >> 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...).

> 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...

Regards.

-- 
J. Mayer <address@hidden>
Never organized





reply via email to

[Prev in Thread] Current Thread [Next in Thread]