Am Sunday, 28. May 2006 20:54 schrieb David T. Lewis:
Hi Martin,
It's been a couple of months since I've tried compiling a VM on amd64, but if noone else replies to this I'll give it a try sometime in the next couple of days and let you know if it works for me. Right now I'm too busy drinking beer and enjoying a long Memorial Day weekend ;) (that's the US holiday to honor war veterans, but also the semi-official first day of summer).
In the past I have seen symptoms like this due to problems in the memory access macros/functions in sqMemoryAccess.h, but it really could be caused by most anything. You should definitely build only the absolutely necessary plugins until you get the VM to run, as many of the plugins are not 64 bit clean.
Dave
What exactly are the absoulutely necessary plugins?
Martin
On Sun, May 28, 2006 at 07:26:11PM +0200, Martin Kuball wrote:
Am Sunday, 28. May 2006 15:24 schrieb Martin Kuball:
Hi!
I compiled a 64/32 bit VM from svn. Immediately after start I get a SIGSEV at: interp.c line 7865:
longAtput(where + ((ReceiverIndex + i) << ShiftForWord), longAtPointer(localSP - ((argCount2 - i) * BytesPerWord)));
I examined the arguments to longAtput and they seem OK. But there is no Memory mapped at sqMemoryBase. How could that happen?
Martin
Forgot to give you some more details. I'm running a amd64 system with linux 2.6.14. Compiler ist gcc 4.0.3.
Martin
On 29-May-06, at 12:51 PM, Martin Kuball wrote:
I examined the arguments to longAtput and they seem OK. But there is no Memory mapped at sqMemoryBase. How could that happen?
Martin
Forgot to give you some more details. I'm running a amd64 system with linux 2.6.14. Compiler ist gcc 4.0.3.
If there is no memory mapped at a fundamental address like sqMemoryBase that implies to me that some very serious has failed, and I think it must surely have failed right at the beginning of starting Squeak. You didn't mention anything about whether the system started up or not, what you were doing, or anything that might help us.
sqMemoryBase is typically set right at the beginning of the VM startup, by allocating the memory for the image so if for some strange reason that fails you could be in trouble. It's hard to imagine how the allocate could fail and not be detected though.
tim -- tim Rowledge; tim@rowledge.org; http://www.rowledge.org/tim Useful Latin Phrases:- Utinam coniurati te in foro interficiant! = May conspirators assassinate you in the mall!
Am Monday, 29. May 2006 23:43 schrieb tim Rowledge:
On 29-May-06, at 12:51 PM, Martin Kuball wrote:
I examined the arguments to longAtput and they seem OK. But there is no Memory mapped at sqMemoryBase. How could that happen?
Martin
Forgot to give you some more details. I'm running a amd64 system with linux 2.6.14. Compiler ist gcc 4.0.3.
If there is no memory mapped at a fundamental address like sqMemoryBase that implies to me that some very serious has failed, and I think it must surely have failed right at the beginning of starting Squeak. You didn't mention anything about whether the system started up or not, what you were doing, or anything that might help us.
sqMemoryBase is typically set right at the beginning of the VM startup, by allocating the memory for the image so if for some strange reason that fails you could be in trouble. It's hard to imagine how the allocate could fail and not be detected though.
Hi!
I compiled a VM with BallonEngine, BitBlitSimulation and FilePlugin. I started the vm in gdb and checked the allocation of the memory. All went well. The reason I reported a bad memory region earlier is that sqMemoryBase is the real base - 16. Now the interpreter loop runs and at its 12th cylce (opcode 134) I still get the SIGSEV. Further investigation showed that foo->stackPointer is the culprit. All the cycles before it had a value of 15723512. But this time the value is 1509280732. Really bad. I will try to find out where this change happens tomorrow.
By the way when compiling I see a lot of warnings like this one:
/home/kuball/SMT/vm-svn/trunk/platforms/unix/mysrc/vm/interp.c:7772: warning: cast from pointer to integer of different size
I'm not sure if it is save to ignore them.
The reason I did not mention anything about system startup is that nothing unusual happend. And it's not the the first time I build a VM. I even have an 64/32 bit VM working here. But it's almost 1 year old and has no network support. Because of that and because I plan to resume work on my xvid plugin I want something more up to date.
Martin
Am Tuesday, 30. May 2006 22:19 schrieb Martin Kuball:
Am Monday, 29. May 2006 23:43 schrieb tim Rowledge:
On 29-May-06, at 12:51 PM, Martin Kuball wrote:
I examined the arguments to longAtput and they seem OK. But there is no Memory mapped at sqMemoryBase. How could that happen?
Martin
Forgot to give you some more details. I'm running a amd64 system with linux 2.6.14. Compiler ist gcc 4.0.3.
If there is no memory mapped at a fundamental address like sqMemoryBase that implies to me that some very serious has failed, and I think it must surely have failed right at the beginning of starting Squeak. You didn't mention anything about whether the system started up or not, what you were doing, or anything that might help us.
sqMemoryBase is typically set right at the beginning of the VM startup, by allocating the memory for the image so if for some strange reason that fails you could be in trouble. It's hard to imagine how the allocate could fail and not be detected though.
Hi!
I compiled a VM with BallonEngine, BitBlitSimulation and FilePlugin. I started the vm in gdb and checked the allocation of the memory. All went well. The reason I reported a bad memory region earlier is that sqMemoryBase is the real base - 16. Now the interpreter loop runs and at its 12th cylce (opcode 134) I still get the SIGSEV. Further investigation showed that foo->stackPointer is the culprit. All the cycles before it had a value of 15723512. But this time the value is 1509280732. Really bad. I will try to find out where this change happens tomorrow.
The only thing I can tell you is that the stackpointer is set from localSP at one point via: foo->stackPointer = oopForPointer(localSP); Now oopForPointer seems to be a simple cast to sqInt (which is a typedef from int). Now casting a pointer to a char to an int might actually leed to problems on a 64bit system. Which indeed it does in this case as 0x2aaaad732bec becomes 0xffffffffad732bec.
Any suggestions what to do now?
Martin
Hi Martin
What exactly are the absoulutely necessary plugins?
The current Spoon VMs are built with BitBlt, File, FloatArray, Security, and Misc (all internal). Problems occurred if I took any of those away, but haven't bothered to investigate yet. They probably aren't all needed.
-C
vm-dev@lists.squeakfoundation.org