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 [EMAIL PROTECTED]
Network & Software Engineering http://www.netsweng.com/
1024D/37A79149: 0791 D3B8 9A4C 2CDC A31F
BD03 0A62 E534 37A7 9149
