Vm-dev July 2005

vm-dev@lists.squeakfoundation.org

4 participants
3 discussions

[OSPP] Status report: 64 bit updates for OSPP, XDCP, and AioPlugin
by David T. Lewis 14 Jul '05

14 Jul '05

I have completed the first phase of the 64 bit updates for OSProcessPlugin, XDisplayControlPlugin, and AioPlugin. The first phase was to do all updates required for compiling and running on 32 bit hardware. The second and last phase is to do any additional updates that will be required for compiling and running on 64 bit hardware. Current status: All three plugins compile cleanly (no warnings or errors) for both the 32 bit VM and the 64 bit VM. All OSProcess unit tests pass for both the 32 bit and 64 bit VM and image when running on 32 bit Intel hardware and Linux OS. On a 32 bit Intel Linux box, OSProcess and CommandShell both work fine on either the 32 bit or 64 bit VM and image. Caveats: - I am generating my plugin code using the latest SVN and VMM sources, but compiling with ./src and ./platforms from the old dist3 files (with symlinks to tie the two together for build). This is due to my inability to build a working VM from the latest sources on my Linux Intel box. Therefore, my tests are not fully valid (although the plugins are clearly working, and I have no specific reason to anticipate other problems). - I have not tested anything on Windows. The Win32 OSProcessPlugin will probably work (relevant changes have been applied to both the Unix and Win32 subclasses), but I have not compiled or tested it. - I do not have a 64 bit computer to work with, so I have no way to know how this stuff will work on an actual 64 bit machine. I am assuming that it will *not* work initially, but I don't expect to need any extensive changes (the changes so far have been straightforward). Help needed: Is anyone in a position to load my OSP code, build the plugins, and run my SUnit test suite on a real 64 bit machine? This would require about a half hour to an hour of work, and the result would be a file with the test results that could be mailed back to me to figure out next steps. I'll provide all the change sets and/or MCZ files (but I don't want to attach all that stuff to this email). I am attaching a copy of the plugins for reference (but not the test suite, OSP updates, etc). Dave

1 0

Problem building from latest SNV & VMM
by David T. Lewis 08 Jul '05

08 Jul '05

Hi, I can build and run 32 bit Intel Linux VMs from the source and image posted in the ./dist3 directory. However, if I use recent platforms source from SVN with recent VMMaker, I get a VM that has some kind of problem apparently involving memory decoding or interpreting an instruction stream. I can occasionally get a small image to start up with this VM (usually I get a crash related to one of the background processes or to an incremental GC at startup), but once running the image cannot accept text in a workspace, or apparently do anything else related to interpreting an instruction stream (???). When the VM crashes, it appears to always involve one of the memory access functions (or macros as the case may be), but it happens at various times after entering the interpreter, and I have not figured anything out by looking at it under gdb. Failures when the image is running may bring up debuggers, as shown in the attached gif. These appear to be failures interpreting a BlockContext and failures related to write stream positioning in the compiler. Presumably this is related to the memory access failures I see when the VM crashes outright. Any ideas? Here are some artifacts of the failing VM/image: world.3.gif is a screen dump of the minimal image after it has successfully started, with some debuggers open. sqMemoryAccess.h is a copy of the lightly hacked file I am using, forcing use of the static inline functions rather than macros (it also includes a couple of missing macros that are not being used for purposes of these tests). SqueakDebugLogFiles.zip contains some representative debug log files that may give some clues as to what is going wrong. I must be looking past something obvious, but I can't spot it. Dave

3 5

Cannot load vm-display-X11 module after build from latest SVN and VMM
by David T. Lewis 02 Jul '05

02 Jul '05

I'm trying to build an up-to-date VM from source in order to get OSPP and XDCP updated for the 64 bit code base. I'm having trouble building a VM from the latest; the vm-display-X11 module will not load. I'm stumped and would appreciate some help. Here's the situation: $ cat /proc/version Linux version 2.4.21-144-default (root(a)i386.suse.de) (gcc version 3.3.1 (SuSE Linux)) #1 Fri Nov 14 00:01:36 UTC 2003 $ squeak -version 3.7b-6 #30 Mon May 2 10:55:50 EDT 2005 gcc 3.3.1 Squeak3.7 of '4 September 2004' [latest update: #5989] Linux dtlewis 2.4.21-144-default #1 Fri Nov 14 00:01:36 UTC 2003 i686 i686 i386 GNU/Linux default plugin location: /usr/local/lib/squeak/3.7b-6/*.so Squeak image is Squeak3.7 of '4 September 2004' [latest update: #5989] I loaded VMMaker-tpr.37.mcz from Tim's site. The platforms source is loaded from SVN as of today (June 30). I built and installed the VM with no errors or warnings related to vm-display-X11. The vm-display-X11 module is correctly installed in /usr/local/lib/squeak/3.8a-2. When I run Squeak I get this: $ squeak sq.image looking for module vm-display-X11 could not find display driver vm-display-X11; either: - check that /usr/local/lib/squeak/3.8a-2/vm-display-X11.so exists, or - use the '-plugins <path>' option to tell me where it is, or - remove DISPLAY from your environment. Aborted I can run the VM under GDB, and I think I see the dlopen() attempting to open the /usr/local/lib/squeak/3.8a-2/vm-display-X11 file, and failing as if the file were not there. But I can copy a vm-display-X11 file from some earlier build into the installation directory, and the VM finds and loads it (but crashes on account of it being a different version). So it does not appear to be a path problem, the VM is looking it the right place, and finding a vm-display-X11 file there. It appears that there is something about the vm-display-X11 file itself that causes it to be unloadable (it's world readable and world executable, so that's not it). The file itself looks fine: $ ls -l /usr/local/lib/squeak/3.8a-2/vm-display-X11 -rwxr-xr-x 1 lewis users 150331 2005-06-30 11:26 /usr/local/lib/squeak/3.8a-2/vm-display-X11 $ file /usr/local/lib/squeak/3.8a-2/vm-display-X11 /usr/local/lib/squeak/3.8a-2/vm-display-X11: ELF 32-bit LSB shared object, Intel 80386, version 1 (SYSV), not stripped And the module built without errors and warnings, so I'm thinking it may be something that has changed recently in the source tree. I feel like Mr. Jones, something is going on but I don't know what to do. Any tips? Thanks, Dave

2 3

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

Vm-dev July 2005