qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
* [Qemu-devel] Insta-segfault! i386-linux-user
@ 2007-09-18 12:32 Thayne Harbaugh
  2007-09-18 13:53 ` Ronald
  0 siblings, 1 reply; 8+ messages in thread
From: Thayne Harbaugh @ 2007-09-18 12:32 UTC (permalink / raw)
  To: qemu-devel

Has anyone seen an insta-segfault with i386-linux-user qemu?  I've
compiled qemu-0.9.0 as well as qemu-cvs (2007-09-18) with gcc-3.4 and
-fno-strict-aliasing on an amd64 and I get this:

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

Nice NULL frame there - and it's before main() is reached.

Install prefix    /usr
BIOS directory    /usr/share/qemu
binary directory  /usr/bin
Manual directory  /usr/share/man
ELF interp prefix /usr/gnemul/qemu-%M
Source path       /home/thayne/dev/c2/qemu-0.9.0
C compiler        gcc-3.4
Host C compiler   gcc (also tried with gcc-3.4)
make              make
install           install
host CPU          x86_64
host big endian   no
target list       i386-linux-user arm-linux-user
gprof enabled     no
profiler          no
static build      no
SDL support       yes
SDL static link   yes
mingw32 support   no
Adlib support     yes
CoreAudio support no
ALSA support      yes
DSound support    no
FMOD support      no
kqemu support     yes
Documentation     yes

CFLAGS            -Wall -fno-strict-aliasing -Wall -ggdb -fno-strict-aliasing
libc              2.6.1-1 (debian lenny)

^ permalink raw reply	[flat|nested] 8+ messages in thread

* Re: [Qemu-devel] Insta-segfault! i386-linux-user
  2007-09-18 12:32 [Qemu-devel] Insta-segfault! i386-linux-user Thayne Harbaugh
@ 2007-09-18 13:53 ` Ronald
  2007-09-18 18:25   ` Thayne Harbaugh
  0 siblings, 1 reply; 8+ messages in thread
From: Ronald @ 2007-09-18 13:53 UTC (permalink / raw)
  To: thayne, qemu-devel

Thayne Harbaugh schreef:
> Has anyone seen an insta-segfault with i386-linux-user qemu?  I've
> compiled qemu-0.9.0 as well as qemu-cvs (2007-09-18) with gcc-3.4 and
> -fno-strict-aliasing on an amd64 and I get this:
>
> ./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 ()
>
> Nice NULL frame there - and it's before main() is reached.
>
> Install prefix    /usr
> BIOS directory    /usr/share/qemu
> binary directory  /usr/bin
> Manual directory  /usr/share/man
> ELF interp prefix /usr/gnemul/qemu-%M
> Source path       /home/thayne/dev/c2/qemu-0.9.0
> C compiler        gcc-3.4
> Host C compiler   gcc (also tried with gcc-3.4)
> make              make
> install           install
> host CPU          x86_64
> host big endian   no
> target list       i386-linux-user arm-linux-user
> gprof enabled     no
> profiler          no
> static build      no
> SDL support       yes
> SDL static link   yes
> mingw32 support   no
> Adlib support     yes
> CoreAudio support no
> ALSA support      yes
> DSound support    no
> FMOD support      no
> kqemu support     yes
> Documentation     yes
>
> CFLAGS            -Wall -fno-strict-aliasing -Wall -ggdb -fno-strict-aliasing
> libc              2.6.1-1 (debian lenny)
>
>
>
>
>
>   
Yes, I had this problem too. U only compiled the program using the 
'user' parameters. But to get the virtualisation going, you need to 
compile at least one 'softmmu' (whatever that is). Doing that will 
create the executable: qemu    (this is the executable you want :)   )

So I run Linux and I compile it with (and I really need it):

i386-linux-user AND i386-softmmu     (i386 can be replaced with your 
arch such as: ppc, sparc, x86_64, mips, mipsel and arm)

That should create an executable called qemu (as stated before) which 
should not segfault immediatly lol :)

                                              Good Luck :)

^ permalink raw reply	[flat|nested] 8+ messages in thread

* Re: [Qemu-devel] Insta-segfault! i386-linux-user
  2007-09-18 13:53 ` Ronald
@ 2007-09-18 18:25   ` Thayne Harbaugh
  2007-09-18 19:11     ` Alexander Graf
  0 siblings, 1 reply; 8+ messages in thread
From: Thayne Harbaugh @ 2007-09-18 18:25 UTC (permalink / raw)
  To: Ronald; +Cc: qemu-devel

On Tue, 2007-09-18 at 15:53 +0200, Ronald wrote:
> Thayne Harbaugh schreef:
> > Has anyone seen an insta-segfault with i386-linux-user qemu?  I've
> > compiled qemu-0.9.0 as well as qemu-cvs (2007-09-18) with gcc-3.4 and
> > -fno-strict-aliasing on an amd64 and I get this:
> >
> > ./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>

> >   
> Yes, I had this problem too. U only compiled the program using the 
> 'user' parameters.

I only compiled the 'user' portion because that's all I want.

>  But to get the virtualisation going, you need to 
> compile at least one 'softmmu' (whatever that is). Doing that will 
> create the executable: qemu    (this is the executable you want :)   )

Err, no.  I don't want full virtualization.

> So I run Linux and I compile it with (and I really need it):
> 
> i386-linux-user AND i386-softmmu     (i386 can be replaced with your 
> arch such as: ppc, sparc, x86_64, mips, mipsel and arm)
> 
> That should create an executable called qemu (as stated before) which 
> should not segfault immediatly lol :)

Thank you for your comments.  User virtualization doesn't require
softmmu.  User virtualization translates the ops in the user space
program and then jumps into the real kernel of the host operating system
when a syscall is made - it therefore doesn't need to virtualize all of
the hardware for I/O and the like.  Obviously this only works for
running linux executables of one architecture on linux of possibly
another architecture.

I might mention that none of the other user-space architectures segfault
- just i386 - e.g. arm-linux-user/qemu-arm works just fine.

^ permalink raw reply	[flat|nested] 8+ messages in thread

* Re: [Qemu-devel] Insta-segfault! i386-linux-user
  2007-09-18 18:25   ` Thayne Harbaugh
@ 2007-09-18 19:11     ` Alexander Graf
  2007-09-18 21:49       ` Thayne Harbaugh
  0 siblings, 1 reply; 8+ messages in thread
From: Alexander Graf @ 2007-09-18 19:11 UTC (permalink / raw)
  To: thayne, qemu-devel


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:
>>> Has anyone seen an insta-segfault with i386-linux-user qemu?  I've
>>> compiled qemu-0.9.0 as well as qemu-cvs (2007-09-18) with gcc-3.4  
>>> and
>>> -fno-strict-aliasing on an amd64 and I get this:
>>>
>>> ./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>
>
>>>
>> Yes, I had this problem too. U only compiled the program using the
>> 'user' parameters.
>
> I only compiled the 'user' portion because that's all I want.
>
>>  But to get the virtualisation going, you need to
>> compile at least one 'softmmu' (whatever that is). Doing that will
>> create the executable: qemu    (this is the executable you  
>> want :)   )
>
> Err, no.  I don't want full virtualization.
>
>> So I run Linux and I compile it with (and I really need it):
>>
>> i386-linux-user AND i386-softmmu     (i386 can be replaced with your
>> arch such as: ppc, sparc, x86_64, mips, mipsel and arm)
>>
>> That should create an executable called qemu (as stated before) which
>> should not segfault immediatly lol :)
>
> Thank you for your comments.  User virtualization doesn't require
> softmmu.  User virtualization translates the ops in the user space
> program and then jumps into the real kernel of the host operating  
> system
> when a syscall is made - it therefore doesn't need to virtualize  
> all of
> the hardware for I/O and the like.  Obviously this only works for
> running linux executables of one architecture on linux of possibly
> another architecture.
>
> I might mention that none of the other user-space architectures  
> segfault
> - just i386 - e.g. arm-linux-user/qemu-arm works just fine.
>
>
>
>

We had this on the list some months ago. 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.  
Be prepared for breakage though, as linux-user on 64-Bit hosts does  
not work properly.

Cheers,

Alex

^ permalink raw reply	[flat|nested] 8+ messages in thread

* Re: [Qemu-devel] Insta-segfault! i386-linux-user
  2007-09-18 19:11     ` Alexander Graf
@ 2007-09-18 21:49       ` Thayne Harbaugh
  2007-09-18 22:07         ` Alexander Graf
  0 siblings, 1 reply; 8+ messages in thread
From: Thayne Harbaugh @ 2007-09-18 21:49 UTC (permalink / raw)
  To: Alexander Graf; +Cc: qemu-devel

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?

Thank you.

^ permalink raw reply	[flat|nested] 8+ messages in thread

* Re: [Qemu-devel] Insta-segfault! i386-linux-user
  2007-09-18 21:49       ` Thayne Harbaugh
@ 2007-09-18 22:07         ` Alexander Graf
  2007-09-18 22:41           ` J. Mayer
  0 siblings, 1 reply; 8+ messages in thread
From: Alexander Graf @ 2007-09-18 22:07 UTC (permalink / raw)
  To: thayne; +Cc: qemu-devel


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

Good luck,

Alex

^ permalink raw reply	[flat|nested] 8+ messages in thread

* Re: [Qemu-devel] Insta-segfault! i386-linux-user
  2007-09-18 22:07         ` Alexander Graf
@ 2007-09-18 22:41           ` J. Mayer
  2007-09-18 22:57             ` Alexander Graf
  0 siblings, 1 reply; 8+ messages in thread
From: J. Mayer @ 2007-09-18 22:41 UTC (permalink / raw)
  To: qemu-devel; +Cc: Alexander Graf, thayne

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 <l_indien@magic.fr>
Never organized

^ permalink raw reply	[flat|nested] 8+ messages in thread

* Re: [Qemu-devel] Insta-segfault! i386-linux-user
  2007-09-18 22:41           ` J. Mayer
@ 2007-09-18 22:57             ` Alexander Graf
  0 siblings, 0 replies; 8+ messages in thread
From: Alexander Graf @ 2007-09-18 22:57 UTC (permalink / raw)
  To: qemu-devel; +Cc: J. Mayer, thayne


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

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

^ permalink raw reply	[flat|nested] 8+ messages in thread

end of thread, other threads:[~2007-09-18 22:57 UTC | newest]

Thread overview: 8+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2007-09-18 12:32 [Qemu-devel] Insta-segfault! i386-linux-user Thayne Harbaugh
2007-09-18 13:53 ` Ronald
2007-09-18 18:25   ` Thayne Harbaugh
2007-09-18 19:11     ` Alexander Graf
2007-09-18 21:49       ` Thayne Harbaugh
2007-09-18 22:07         ` Alexander Graf
2007-09-18 22:41           ` J. Mayer
2007-09-18 22:57             ` Alexander Graf

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).