VM build problem: sqInt?
Locked
 
|
I'm attempting to build a VM for a 64-bit Intel mac, using image version #7051 and VM version 3.8.12.beta5U, and revision 1520 of the C sources. I follow the usual steps regarding VMMaker, Balloon 3D, special change sets, and gnuification. If I check "64 bit VM" in VMMaker, generate sources, gnuify, and compile I get these compilation errors: conflicting types for ioExit: int ioExit(void) { previous declaration of ioExit was here: sqInt ioExit(void); and ditto for: ioDisablePowerManager, ioBeep, ioFormPrint, attributeSize, etc and also a few in sqMacTime: ioMicroMSecs, ioSeconds, ... If I uncheck "64 bit VM", clean out sources, regenerate, etc, then I get these undefined's from ld: _ioFilenamefromStringofLengthresolveAliases _vmEndianness Has anyone else had a similar experience? I'd prefer to build the 64-bit version if possible. Thanks a million for any suggestions. Jay |
|
|
I think if you look in the squeak mailing list for
ioFilenamefromStringofLengthresolveAliases, vmEndianness you'll find lots of discussion about the missing vmEndianness and the ioFilenamefromStringofLengthresolveAliases I believe was added later so perhaps the vmmaker you have or the C source code for 64bit support is lacking it. On 2-Sep-06, at 2:04 AM, Jay Hardesty wrote: > > I'm attempting to build a VM for a 64-bit Intel mac, using image > version #7051 > and VM version 3.8.12.beta5U, and revision 1520 of the C sources. > > > I follow the usual steps regarding VMMaker, Balloon 3D, special > change sets, > and gnuification. > > > If I check "64 bit VM" in VMMaker, generate sources, gnuify, and > compile > I get these compilation errors: > conflicting types for ioExit: > int ioExit(void) { > previous declaration of ioExit was here: > sqInt ioExit(void); > > and ditto for: ioDisablePowerManager, ioBeep, ioFormPrint, > attributeSize, etc > and also a few in sqMacTime: ioMicroMSecs, ioSeconds, ... > > > If I uncheck "64 bit VM", clean out sources, regenerate, etc, then > I get > these undefined's from ld: > _ioFilenamefromStringofLengthresolveAliases > _vmEndianness > > > Has anyone else had a similar experience? I'd prefer to build the > 64-bit > version if possible. Thanks a million for any suggestions. > > Jay > -- ======================================================================== === John M. McIntosh <[hidden email]> Corporate Smalltalk Consulting Ltd. http://www.smalltalkconsulting.com ======================================================================== === |
|
|
Yes I did look through the lists. The only discussions I found regarding vmEndianness related to configuration problems and directory structure changes for the unix build. I also see proposals for change to earlier versions of the code, but as far as I know I have the latest versions, (at least the sources and VMMaker recommended by the readme file in the source distribution: VMMaker-tpr.37.mcz). I've been using the nabble search facility for the squeak lists - perhaps there is some more comprehensive one? Also, if the latest VMMaker and C sources lack support for ioFilenamefromStringofLengthresolveAliases, then is there some earlier version I should check out (either of the sources, or VMMaker, or...)? Not trying to be lazy about this by turning to the list - have been trying for days to figure out how to get this to work. Has anyone actually built a Mac VM with any recent combination of source and VMMaker versions? Is there any way to know what combination most recently worked? If anyone has any pointers to discussions that address these undefined's for the Mac build, then I'd be very grateful. Or does a build at this time require implementing missing C functions by hand (and familiarity with the VM sources)? Also is it the case then that checking "64 bit VM" is a no-go for Mac builds? I couldn't find any discussions that resolved the sqInt vs. int declarations. Thanks for any pointers, Jay On Sep 2, 2006, at 11:24 PM, John M McIntosh wrote: > I think if you look in the squeak mailing list for > ioFilenamefromStringofLengthresolveAliases, vmEndianness > you'll find lots of discussion about the missing vmEndianness and > the ioFilenamefromStringofLengthresolveAliases I believe was added > later so perhaps the vmmaker you have or the C source code for > 64bit support is lacking it. > > > On 2-Sep-06, at 2:04 AM, Jay Hardesty wrote: > >> >> I'm attempting to build a VM for a 64-bit Intel mac, using image >> version #7051 >> and VM version 3.8.12.beta5U, and revision 1520 of the C sources. >> >> >> I follow the usual steps regarding VMMaker, Balloon 3D, special >> change sets, >> and gnuification. >> >> >> If I check "64 bit VM" in VMMaker, generate sources, gnuify, and >> compile >> I get these compilation errors: >> conflicting types for ioExit: >> int ioExit(void) { >> previous declaration of ioExit was here: >> sqInt ioExit(void); >> >> and ditto for: ioDisablePowerManager, ioBeep, ioFormPrint, >> attributeSize, etc >> and also a few in sqMacTime: ioMicroMSecs, ioSeconds, ... >> >> >> If I uncheck "64 bit VM", clean out sources, regenerate, etc, then >> I get >> these undefined's from ld: >> _ioFilenamefromStringofLengthresolveAliases >> _vmEndianness >> >> >> Has anyone else had a similar experience? I'd prefer to build the >> 64-bit >> version if possible. Thanks a million for any suggestions. >> >> Jay >> > > -- > ====================================================================== > ===== > John M. McIntosh <[hidden email]> > Corporate Smalltalk Consulting Ltd. http:// > www.smalltalkconsulting.com > ====================================================================== > ===== > > > |
|
|
In reply to this post by johnmci
>
> On 2-Sep-06, at 2:04 AM, Jay Hardesty wrote: > >> >> I'm attempting to build a VM for a 64-bit Intel mac, using image >> version #7051 >> and VM version 3.8.12.beta5U, and revision 1520 of the C sources. >> >> >> I follow the usual steps regarding VMMaker, Balloon 3D, special >> change sets, >> and gnuification. >> >> >> If I check "64 bit VM" in VMMaker, generate sources, gnuify, and >> compile >> I get these compilation errors: >> conflicting types for ioExit: >> int ioExit(void) { >> previous declaration of ioExit was here: >> sqInt ioExit(void); Well ioExit is declared as sqInt ioExit(void); in sq.h but appears to be int ioExit(void) { in sqMacMain.c. Whoops. >> >> and ditto for: ioDisablePowerManager, ioBeep, ioFormPrint, >> attributeSize, etc >> and also a few in sqMacTime: ioMicroMSecs, ioSeconds, ... >> >> >> If I uncheck "64 bit VM", clean out sources, regenerate, etc, then >> I get >> these undefined's from ld: >> _ioFilenamefromStringofLengthresolveAliases >> _vmEndianness These should be in the generated interp.c file so if they're not, either you have a wrong version of VMMaker or some strange thing is going wrong. tim -- tim Rowledge; [hidden email]; http://www.rowledge.org/tim Useful random insult:- The wheel's spinning but the hamster's dead. |
|
|
In reply to this post by jayh
On 2-Sep-06, at 9:38 PM, Jay Hardesty wrote: > > Yes I did look through the lists. The only discussions I found > regarding > vmEndianness related to configuration problems and directory structure > changes for the unix build. I also see proposals for change to > earlier > versions of the code, but as far as I know I have the latest versions, > (at least the sources and VMMaker recommended by the readme > file in the source distribution: VMMaker-tpr.37.mcz). Oh my, the 'Slathering SafflowerOil release? - that is seriously out of date Jay. Two years is it? Something like that anyway. You need the 3.8b6 'EndOfTheRoad' version and a 3.8.1 image - http://map1.squeakfoundation.org/package/2e7f103e-22a6-470d- affe-54b1d04ef34a for the vmmaker package. Use SVN to get latest source tree. > > Not trying to be lazy about this by turning to the list - have been > trying > for days to figure out how to get this to work. Has anyone actually > built a Mac VM with any recent combination of source and VMMaker > versions? Yup, the current running Mac vm is built from the above combo, as is the RISC OS vm etc. > Is there any way to know what combination most recently > worked? If anyone has any pointers to discussions that address > these undefined's for the Mac build, then I'd be very grateful. Or > does > a build at this time require implementing missing C functions by hand > (and familiarity with the VM sources)? That should never be the case, though on occasion one or other of us does mange to cause a small break. Generally a version of VMmaker combined with a matching level of the svn tree and a contemporaneous image will work since it is what is used to build 'production' vms. > > Also is it the case then that checking "64 bit VM" is a no-go for > Mac builds? John points out that no attempt has been made so far as he knows to build a 64bit Carbon version. tim -- tim Rowledge; [hidden email]; http://www.rowledge.org/tim Klingon Code Warrior:- 3) "Perhaps it IS a good day to Die! I say we ship it!" |
|
|
On Sep 3, 2006, at 12:55 AM, tim Rowledge wrote:
OK, I won't ask... Any case, thanks - the VMMaker/image combo you recommended got me apparently closer to success. The only remaining problem is: error: conflicting types for 'flag' static sqInt flag(sqInt aSymbol); (LargeIntegers.c:68) previous definition of 'flag' was here static void inline flag(char *ignored) {} (sqMemoryAccess.h:166) The latest code from svn is revision 1520. I also tried revision 1444 based on the comment on the "EndOfTheRoad" VMMaker page, but get the same result. (Quick scan of the mailing list didn't turn up anything)
Perhaps the text in platforms/Mac OS/vm/Documentation/readme (in revision 1520 of the sources) should be changed from: "0. Grab your 3.9 image, and then install the 32/64bit version of VMMaker or better, and Balloon 3D. As of Nov 10th 2005, You need a beta VMMaker from to: "0. Grab your 3.8.1 image, install Balloon 3D, and then install version 3.8b6 of VMMaker, from ?? Now interp.c does contain the variables that were previously undefined, and it's definitely helpful to know that I shouldn't be trying to build with the "64-bit VM" checked. Thanks again for the info, Jay |
|
|
In reply to this post by jayh
On Sun, 03 Sep 2006 06:38:39 +0200, Jay Hardesty wrote:
... > I've been using the nabble search facility for the squeak lists - > perhaps there is some more comprehensive one? Try & compare - http://www.google.com/search?q=vmEndianness+site:lists.squeakfoundation.org v.s. - http://www.google.com/search?q=vmEndianness+Squeak /Klaus |
|
|
In reply to this post by jayh
I tried to patch around the conflicting definitions for flag, by moving the second one into sqVirtualMachine.c (and removing "inline"). That problem then seems to go away (or at least into hiding for the moment). Now I get as far as compiling interp.c, wherein occurs: error: invalid operands to binary+ return longAt(((((char *) oop)) + BaseHeaderSize) + (fieldIndex << 2)); This is at line 4343 of interp.c in function fetchWordofObject. This is from a fresh setup using: revision 1444 of the C code (revision 1520 yields the same outcome) VMMaker 3.8b6 Squeak3.8-6665full.image Squeak 3.8.12beta4U.app Question: should I still be filing in the special change sets: VMM38-64bit-imageUpdates.1.cs VMM38-gc-instrument-image.1.cs for use with VMMaker 3.8b6? (The readme indicates these should be filed in after loading version 3.7, along with ArraysToGlobalStruct-JMM.1.cs and Gnuifier.6.cs) Thanks -Jay On Sep 3, 2006, at 2:35 AM, Jay Hardesty wrote:
|
|
|
On 3-Sep-06, at 12:22 AM, Jay Hardesty wrote: > > I tried to patch around the conflicting definitions for flag, > by moving the second one into sqVirtualMachine.c (and > removing "inline"). That problem then seems to go away > (or at least into hiding for the moment). Deleting the static sqInt flag(sqInt aSymbol); (LargeIntegers.c:68) in LargeIntegers.c is the more correct solution. -- ======================================================================== === John M. McIntosh <[hidden email]> Corporate Smalltalk Consulting Ltd. http://www.smalltalkconsulting.com ======================================================================== === |
|
|
In reply to this post by jayh
I've update the readme file and note
> VMM38-64bit-imageUpdates.1.cs > VMM38-gc-instrument-image.1.cs may or may not be needed depending on the VMMaker version used and the image used. Some of the changes relied on updates to the image stream, some relied on updates to the VMMaker stream. On 3-Sep-06, at 12:22 AM, Jay Hardesty wrote: > > Question: should I still be filing in the special change sets: > VMM38-64bit-imageUpdates.1.cs > VMM38-gc-instrument-image.1.cs > for use with VMMaker 3.8b6? (The readme indicates these should be > filed > in after loading version 3.7, along with ArraysToGlobalStruct-JMM.1.cs > and Gnuifier.6.cs) -- ======================================================================== === John M. McIntosh <[hidden email]> Corporate Smalltalk Consulting Ltd. http://www.smalltalkconsulting.com ======================================================================== === |
|
|
In reply to this post by jayh
I note in
http://www-sor.inria.fr/~piumarta/squeak/devel/src/vm/interp.c int fetchWordofObject(int fieldIndex, int oop) { return longAt(((((char *) oop)) + BaseHeaderSize) + (fieldIndex << 2)); } however this private dated copy of interp.c which contains fetchWordofObject is not found in the current build I'll note to confuse XCode the platform/unix/ tree contains src src32 src64 you should delete those directories to avoid confusion, normally this is not a problem but I have to wonder where xcode thinks it is finding your interp.c If your copy of interp.c then still contains fetchWordofObject then something is wrong. I'll note my copy of interp.c says: /* Automatically generated from Squeak on #(17 April 2006 7:32:49 pm) by VMMaker 3.8b6 */ On 3-Sep-06, at 12:22 AM, Jay Hardesty wrote: > > I tried to patch around the conflicting definitions for flag, > by moving the second one into sqVirtualMachine.c (and > removing "inline"). That problem then seems to go away > (or at least into hiding for the moment). > > Now I get as far as compiling interp.c, wherein occurs: > > error: invalid operands to binary+ > return longAt(((((char *) oop)) + BaseHeaderSize) + (fieldIndex > << 2)); > > This is at line 4343 of interp.c in function fetchWordofObject. ======================================================================== === John M. McIntosh <[hidden email]> Corporate Smalltalk Consulting Ltd. http://www.smalltalkconsulting.com ======================================================================== === |
|
|
In reply to this post by jayh
I compared the VMMaker 3.8b6 squeakmap version of interp.c to my
interp.c to ensure I've not missed something and I'll note I updated gnuifer.cs to gunifer.7.cs to remove some register defines so that we get sqInt interpret(void) { #ifdef FOO_REG register struct foo * foo FOO_REG = &fum; #endif sqInt localReturnValue; sqInt localReturnContext; sqInt localHomeContext; char* localSP; char* localIP; sqInt currentBytecode; JUMP_TABLE; browserPluginInitialiseIfNeeded(); in the past we had register keywords as register char* localSP SP_REG; register char* localIP IP_REG; register sqInt currentBytecode CB_REG; But that confused the mac intel gcc compiler so that it produced ugly poorly performing code. The current mac power pc version of gcc 3.3 does the right thing, however we still have to hint with the register struct foo * foo FOO_REG = &fum; otherwise it does the wrong thing. Some would argue that register is obsolete and ignored, but I think your milage varies depending on which compiler is being abused. The check is compare the 3.8.12b5u official VM tinybenchmarks (multiple iterations) against a VM you have built to see if the numbers are close or identical... If not well we get to explore why. -- ======================================================================== === John M. McIntosh <[hidden email]> Corporate Smalltalk Consulting Ltd. http://www.smalltalkconsulting.com ======================================================================== === |
|
|
In reply to this post by johnmci
THANKS for all the pointers - I started from scratch, fetched the latest everything, deleted the flag function in LargeIntegers, and recompiled. However still getting the fetchWordofObject error below. I was careful to make sure there's no src vs. src32 directory confusion, and my interp.c says: /* This file has been post-processed for GNU C */ /* Automatically generated from Squeak on #(3 September 2006 5:28:44 pm) by VMMaker 3.8b6 */ The only change I made to the xcode project was to uncheck "ppc" as a target (since I don't need ppc, and in any case my machine didn't come with the required MacOSX10.2.8.sdk). BUT if if simply comment out fetchWordOfObject the VM compiles and seems to run OK. tinyBenchmarks reports (for an optimized build): '606635071 bytecodes/sec; 13344127 sends/sec' on a 2.66 GHz Mac Pro. Whereas I get '609161213 bytecodes/sec; 13392546 sends/sec' for Squeak 3.8.12beta5U.app. So I guess the newly built VM is in the ballpark, if slightly slower. Thanks once again very much for all the help - let me know if there's any useful info I can provide you with regarding my setup and the fetchWordofObject problem (though it doesn't seem to be causing a problem - as far as I can tell - once it's commented out). Your fan, Jay On Sep 3, 2006, at 3:16 PM, John M McIntosh wrote:
|
|
|
Jay, send me the interp.c (to me not the list of course), so I can
take a peek at it. Also I'll note that if you dump the instructions for interp.c and look for .globl _interpret _interpret: then after the long set of .long LXXXXX you should have L10170: addl $1, %esi movzbl (%esi), %ebx addl $4, %edi movl _foo, %eax movl 84(%eax), %eax movl 4(%eax), %eax movl %eax, (%edi) movl 528(%esp,%ebx,4), %eax L10430: jmp *%eax What's important here is the number of instructions for the first bytecode, nine. More than 9 means things aren't quite right. On 3-Sep-06, at 3:55 PM, Jay Hardesty wrote: > > THANKS for all the pointers - I started from scratch, fetched the > latest > everything, deleted the flag function in LargeIntegers, and > recompiled. > However still getting the fetchWordofObject error below. -- ======================================================================== === John M. McIntosh <[hidden email]> Corporate Smalltalk Consulting Ltd. http://www.smalltalkconsulting.com ======================================================================== === |
«
Return to Squeak - Dev
|
1 view|%1 views
| Free forum by Nabble | Edit this page |