From: Stuart Anderson <anderson@netsweng.com>
To: qemu-devel@nongnu.org
Subject: Re: [Qemu-devel] linux-user target
Date: Thu, 19 Apr 2007 13:04:59 -0400 [thread overview]
Message-ID: <Pine.CYG.4.58.0704191248040.2672@v3-rdg-02.stuart.c2> (raw)
In-Reply-To: <1176971522.6333.98.camel@rapid>
On Thu, 19 Apr 2007, J. Mayer wrote:
> And I checked the code generated on my machine.
> I got the repz at the end of the op_goto_tb0 and op_goto_tb1 and it
> seems to work well here with the bash version I got.
IIrc from yesterday, they ended up in front of lea instuctions, which
I think always resulted in the same value being used, so no harm could
be done.
More digging last night, and this morning, and I have disovered that
a 32-bit build from the x86 system that works fine on the 32-bit system
will crash when run inside a 32-bit chroot on the x86_64 system (with
the save version of libraries in the chroot as are on the 32-bit system).
This suggests that there may be something in the execution environment
that is causing the problem. I traced both runs, and am comparing the
results. The first difference is where things get placed in the address
space. Stuff that is at 0x5xxxxxxx on one is at 0x7xxxxxxx on the other.
Same for 0xaxxxxxxxx and 0xfxxxxxxx. This doesn't seem to cause much of
a problem becasue if I use a simple text substitution on the log files, the
differences almost completely go away. At least that is true for the first
50,000 lines of the logs. Then, for some reason I haven't figured out yet,
the two instances start executing different instructions inside the guest.
I'll need to dig more to figure out it going on when that happens.
Another test which might be interesting is to trade executables with someone
that has a working build on an x86_64 system. The crash will either follow
my executable to someone elses system or their perfectly good executables
will start crashing on my system. I suspect it will be the latter, but it
would be nice to confirm it.
Note that I've had this system running under stress for quite a while now,
including a lot of runtime w/ qemu-arm, so I'm pretty certain it isn't
something mundane like bad RAM.
Sigh... it saddens me to think of the improvements to the rest of linux-user
that I could have finished in the amount of time I've spent on thhis one
problem 8-(.
Stuart
Stuart R. Anderson anderson@netsweng.com
Network & Software Engineering http://www.netsweng.com/
1024D/37A79149: 0791 D3B8 9A4C 2CDC A31F
BD03 0A62 E534 37A7 9149
prev parent reply other threads:[~2007-04-19 17:10 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-04-10 13:34 [Qemu-devel] (no subject) Stuart Anderson
2007-04-10 18:11 ` [Qemu-devel] linux-user target Jocelyn Mayer
2007-04-10 18:27 ` Stuart Anderson
2007-04-17 20:55 ` Stuart Anderson
2007-04-18 17:31 ` Stuart Anderson
2007-04-18 18:43 ` J. Mayer
2007-04-18 19:30 ` Stuart Anderson
2007-04-18 19:52 ` Igor Kovalenko
2007-04-18 20:15 ` Stuart Anderson
2007-04-18 20:32 ` Igor Kovalenko
2007-04-18 20:42 ` Stuart Anderson
2007-04-19 8:32 ` J. Mayer
2007-04-19 17:04 ` Stuart Anderson [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=Pine.CYG.4.58.0704191248040.2672@v3-rdg-02.stuart.c2 \
--to=anderson@netsweng.com \
--cc=qemu-devel@nongnu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
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).