Segmentation fault with 0.50 and 0.51 and fedora core ls

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.

To replicate the problem, copy over ls and any dependent libraries to
the yellowdog 3.0.1 box.  run ls with qemu 0.51.  qemu will quit with a
segmentation fault.  Doing some simple debugging indicates that there is
a null pointer that is dereferenced somewhere in the synthetic cpu
code.  See my other posts from last month for the exact place in the
code; I don't have the capabilities to debug qemu until I return from
vacation.

Re: Segmentation fault with 0.50 and 0.51 and fedora core ls

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.

--

-- 

Re: Segmentation fault with 0.50 and 0.51 and fedora core ls

On Thu, 2004-01-01 at 20:26, J. Mayer wrote:
> 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 ?

qemu was compiled on my yellowdog ppc box, which doesn't use the nptl
glibc-2.3.3.  I think it's still glibc-2.3.1, without nptl.

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

I guess I'll have to try downloading a non-nptl x86 glibc and try that. 
But it would be nice to figure out how to get the nptl glibc working
with qemu (even in non-nptl mode, since nptl would depend on the kernel
support).

Since many of the exe's I'd be wanting to run depend on GLIBC_2.3, I
could compile a special version of glibc that doesn't use nptl.  Would
that work?  Or are there still internal changes that would prohibit this
right now?

Re: Segmentation fault with 0.50 and 0.51 and fedora core ls

On Fri, 2004-01-02 at 05:47, Michael Torrie wrote:
> On Thu, 2004-01-01 at 20:26, J. Mayer wrote:
> > 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 ?
> 
> qemu was compiled on my yellowdog ppc box, which doesn't use the nptl
> glibc-2.3.3.  I think it's still glibc-2.3.1, without nptl.

May the changes has been made between glibc 2.3.1 and following versions
? Strange idea... I have to check this...

> > 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...
> 
> I guess I'll have to try downloading a non-nptl x86 glibc and try that. 
> But it would be nice to figure out how to get the nptl glibc working
> with qemu (even in non-nptl mode, since nptl would depend on the kernel
> support).

sparc?

hello everyone...

I was going to see what the status of qemu was/is for sparc.

When you get the software try to "configure" ... you get some bad substitutions
errors (the configure path with he % in front, and then the source_path%/, after
that, it's "uname -p" instead of "uname -m" :-< ) ... even after that, compiling
fails on the first target (dropping the -n in the config-host.h file seems to get past
that, but then the compile just blows up. 

:-<

Does anyone have a binary of this for solaris/sparc/2.8?

I'm willing to test/make/configure/etc.

Scott

**********************************************************************
This communication is confidential and is intended only for the person to whom it is addressed.  If you are
not that person you are not permitted to make use of the information and you are requested to notify
Commerzbank Aktiengesellschaft, New York Branch immediately that you have received it and then to
destroy the copy in your possession.  Views expressed in this e-mail do not necessarily reflect the views
of Commerzbank AG.
**********************************************************************

Re: sparc?

Hi,

QEMU only works on sparc-linux. However, if someone gives me an access 
to a sparc/solaris workstation, I can try to make the system emulator work.

Fabrice.

Yelich, Scott D. wrote:
> 
> hello everyone...
> 
> I was going to see what the status of qemu was/is for sparc.
> 
> When you get the software try to "configure" ... you get some bad substitutions
> errors (the configure path with he % in front, and then the source_path%/, after
> that, it's "uname -p" instead of "uname -m" :-< ) ... even after that, compiling
> fails on the first target (dropping the -n in the config-host.h file seems to get past
> that, but then the compile just blows up. 
> 
> :-<
> 
> Does anyone have a binary of this for solaris/sparc/2.8?
> 
> I'm willing to test/make/configure/etc.
> 
> Scott
> 
> 
> **********************************************************************
> This communication is confidential and is intended only for the person to whom it is addressed.  If you are

Re: sparc?

try testdrive.compaq.com ;) , they have many types of systems, and free
shells
nuno

----- Original Message -----
From: "Fabrice Bellard" <fabrice.bellard <at> free.fr>
To: <qemu-devel <at> nongnu.org>
Sent: Friday, January 02, 2004 6:16 PM
Subject: Re: [Qemu-devel] sparc?

> Hi,
>
> QEMU only works on sparc-linux. However, if someone gives me an access
> to a sparc/solaris workstation, I can try to make the system emulator
work.
>
> Fabrice.
>
> Yelich, Scott D. wrote:
> >
> > hello everyone...
> >
> > I was going to see what the status of qemu was/is for sparc.
> >
> > When you get the software try to "configure" ... you get some bad
substitutions
> > errors (the configure path with he % in front, and then the
source_path%/, after
> > that, it's "uname -p" instead of "uname -m" :-< ) ... even after that,
compiling

Re: sparc?

Maybe we can arrange to hook you up with a Darwin based machine, if you 
would like to try to make it work on that platform. 

On Jan 2, 2004, at 10:16 AM, Fabrice Bellard wrote:

> Hi,
>
> QEMU only works on sparc-linux. However, if someone gives me an access 
> to a sparc/solaris workstation, I can try to make the system emulator 
> work.
>
> Fabrice.
>
> Yelich, Scott D. wrote:
>> hello everyone...
>> I was going to see what the status of qemu was/is for sparc.
>> When you get the software try to "configure" ... you get some bad 
>> substitutions
>> errors (the configure path with he % in front, and then the 
>> source_path%/, after
>> that, it's "uname -p" instead of "uname -m" :-< ) ... even after 
>> that, compiling
>> fails on the first target (dropping the -n in the config-host.h file 
>> seems to get past
>> that, but then the compile just blows up. :-<
>> Does anyone have a binary of this for solaris/sparc/2.8?
>> I'm willing to test/make/configure/etc.
>> Scott
>> **********************************************************************
>> This communication is confidential and is intended only for the 

Re: Segmentation fault with 0.50 and 0.51 and fedora core ls

On Fri, 2004-01-02 at 06:14, J. Mayer wrote:
> Well, you may rebuild qemu as a static binary on your yellowdog
> distribution. If it compiles without a problem, you'll win 
> It seems really more simple than trying to make two glibc available on
> your system...

What does this have to do with my problem of qemu segfaulting when I run
x86 binaries?  qemu builds and runs just fine.  So that's not the
problem.  It already compiles.  Making qemu static will not help my
problem with glibc (remember it's the x86 glibc that's causing the
problems, not the ppc version).  This is a bug in how qemu interacts
with the x86 glibc (in the gnemul folder).  Not saying that it's not
related to the ppc glibc; just that what you're telling me doesn't seem
to fit with my problem.

To recap, xeyes, xterm, ddd, acrobat reader all work under qemu.  I
copied them straight off my fedora core box.  on my ppc yellowdog box,
qemu can run them just fine.  Even a simple hello world that I compiled
works.  However most other binaries cause qemu to segfault with a null
pointer problem, caused most likely by an interaction between qemu and
the x86 glibc stored in the /usr/gnemul folder.

Michael

Michael

Re: sparc?

Hear Hear!

On Jan 2, 2004, at 4:49 PM, Raymond W. Lucke IV wrote:

> Maybe we can arrange to hook you up with a Darwin based machine, if 
> you would like to try to make it work on that platform. 
>
> On Jan 2, 2004, at 10:16 AM, Fabrice Bellard wrote:
>
>> Hi,
>>
>> QEMU only works on sparc-linux. However, if someone gives me an 
>> access to a sparc/solaris workstation, I can try to make the system 
>> emulator work.
>>
>> Fabrice.

_______________________________________________
Qemu-devel mailing list
Qemu-devel <at> nongnu.org
http://mail.nongnu.org/mailman/listinfo/qemu-devel