On Wed, Apr 02, 2014 at 10:17:56PM +0000, commits@source.squeak.org wrote:
Eliot Miranda uploaded a new version of VMMaker to project VM Maker: http://source.squeak.org/VMMaker/VMMaker.oscog-eem.662.mcz
<bump>
Hi Eliot,
Don't forget to move #minLargeHeaderSize and #sizeHeader:putBodySize: into the VMMaker package next time you do a commit :-)
vm/vm.a(gcc3x-cointerp.o): In function `allInstancesOf': /var/lib/jenkins/workspace/CogVM/src/vm/gcc3x-cointerp.c:9592: undefined reference to `minLargeHeaderSize' /var/lib/jenkins/workspace/CogVM/src/vm/gcc3x-cointerp.c:9593: undefined reference to `sizeHeaderputBodySize' /var/lib/jenkins/workspace/CogVM/src/vm/gcc3x-cointerp.c:9664: undefined reference to `sizeHeaderputBodySize'
Thanks, Dave
thank you Dave and Eliot for following through on this.
tty
---- On Wed, 02 Apr 2014 17:31:39 -0700 David T. Lewis<lewis@mail.msen.com> wrote ----
On Wed, Apr 02, 2014 at 10:17:56PM +0000, commits@source.squeak.org wrote: > > Eliot Miranda uploaded a new version of VMMaker to project VM Maker: > http://source.squeak.org/VMMaker/VMMaker.oscog-eem.662.mcz >
<bump>
Hi Eliot,
Don't forget to move #minLargeHeaderSize and #sizeHeader:putBodySize: into the VMMaker package next time you do a commit :-)
vm/vm.a(gcc3x-cointerp.o): In function `allInstancesOf': /var/lib/jenkins/workspace/CogVM/src/vm/gcc3x-cointerp.c:9592: undefined reference to `minLargeHeaderSize' /var/lib/jenkins/workspace/CogVM/src/vm/gcc3x-cointerp.c:9593: undefined reference to `sizeHeaderputBodySize' /var/lib/jenkins/workspace/CogVM/src/vm/gcc3x-cointerp.c:9664: undefined reference to `sizeHeaderputBodySize'
Thanks, Dave
oops. they were in another package. done. thx!
On Wed, Apr 2, 2014 at 5:31 PM, David T. Lewis lewis@mail.msen.com wrote:
On Wed, Apr 02, 2014 at 10:17:56PM +0000, commits@source.squeak.org wrote:
Eliot Miranda uploaded a new version of VMMaker to project VM Maker: http://source.squeak.org/VMMaker/VMMaker.oscog-eem.662.mcz
<bump>
Hi Eliot,
Don't forget to move #minLargeHeaderSize and #sizeHeader:putBodySize: into the VMMaker package next time you do a commit :-)
vm/vm.a(gcc3x-cointerp.o): In function `allInstancesOf': /var/lib/jenkins/workspace/CogVM/src/vm/gcc3x-cointerp.c:9592: undefined reference to `minLargeHeaderSize' /var/lib/jenkins/workspace/CogVM/src/vm/gcc3x-cointerp.c:9593: undefined reference to `sizeHeaderputBodySize' /var/lib/jenkins/workspace/CogVM/src/vm/gcc3x-cointerp.c:9664: undefined reference to `sizeHeaderputBodySize'
Thanks, Dave
Howdy all.
I will be debugging the SqueakSSL plugin on Linux tomorrow or so and am planning on using DDD to connect to a running process and see what I can see.
Is this the approach you folks would use? or are there better methods for approaching this.
thx.
tty
On 03.04.2014, at 22:44, gettimothy gettimothy@zoho.com wrote:
Howdy all.
I will be debugging the SqueakSSL plugin on Linux tomorrow or so and am planning on using DDD to connect to a running process and see what I can see.
Is this the approach you folks would use? or are there better methods for approaching this.
Sounds reasonable.
- Bert -
On Thu, Apr 03, 2014 at 01:44:42PM -0700, gettimothy wrote:
Howdy all.
I will be debugging the SqueakSSL plugin on Linux tomorrow or so and am planning on using DDD to connect to a running process and see what I can see.
Is this the approach you folks would use? or are there better methods for approaching this.
Sure, connecting the debugger to the running VM process will let you debug the primitive. Compile it with CFLAGS=-g (debugger symbols, no compiler optimization). It can be tricky because the primitive function will not be visible until the plugin has been loaded, so you can't set the breakpoint until after the plugin module is loaded, which can be annoying if the primitive causes the VM to crash.
Here is another debugging technique, but I have to warn you that it is a super top secret technique known only to VM gurus, so don't let anybody know I told you about this. After you generate the sources for the plugin, put some printf's in the source code to print out the values of the variables or addresses or object pointers that you think may be causing a problem. It's crude, but sometimes this is easier than trying to capture the problem in a debugger.
If you are debugging a plugin that works when compiled for 32-bits and crashes the VM when compiled for 64-bits, the problems are usually associated with somebody trying to stuff a 64-bit C pointer into a 32-bit sqInt variable. Look for this kind of problem, and print the object pointers and variables with "%lx" in the printf statements.
Put a "fflush(stdout)" after your printf statements to make sure your debugging output gets flushed out to the console right away.
Dave
David and Bert.
Thank you very much for the pointers.
David,
The printf-fu is strong with me!
Seriously, on Linux the SqueakSSL plugin never loads (or stays loaded longer than a primitive fail) so that will definitely come in handy.
Thanks again.
tty
---- On Thu, 03 Apr 2014 20:01:50 -0700 David T. Lewis <lewis@mail.msen.com> wrote ----
On Thu, Apr 03, 2014 at 01:44:42PM -0700, gettimothy wrote: > > Howdy all. > > I will be debugging the SqueakSSL plugin on Linux tomorrow or so and am planning on using DDD to connect to a running process and see what I can see. > > Is this the approach you folks would use? or are there better methods for approaching this. >
Sure, connecting the debugger to the running VM process will let you debug the primitive. Compile it with CFLAGS=-g (debugger symbols, no compiler optimization). It can be tricky because the primitive function will not be visible until the plugin has been loaded, so you can't set the breakpoint until after the plugin module is loaded, which can be annoying if the primitive causes the VM to crash.
Here is another debugging technique, but I have to warn you that it is a super top secret technique known only to VM gurus, so don't let anybody know I told you about this. After you generate the sources for the plugin, put some printf's in the source code to print out the values of the variables or addresses or object pointers that you think may be causing a problem. It's crude, but sometimes this is easier than trying to capture the problem in a debugger.
If you are debugging a plugin that works when compiled for 32-bits and crashes the VM when compiled for 64-bits, the problems are usually associated with somebody trying to stuff a 64-bit C pointer into a 32-bit sqInt variable. Look for this kind of problem, and print the object pointers and variables with "%lx" in the printf statements.
Put a "fflush(stdout)" after your printf statements to make sure your debugging output gets flushed out to the console right away.
Dave
On Thu, Apr 03, 2014 at 01:44:42PM -0700, gettimothy wrote:
Howdy all.
I will be debugging the SqueakSSL plugin on Linux tomorrow or so and am planning on using DDD to connect to a running process and see what I can see.
Regarding the SqueakSSL plugin, there are two Mantis entries that you should read for background:
http://bugs.squeak.org/view.php?id=7751
http://bugs.squeak.org/view.php?id=7793
IIRC, the SqueakSSL plugin works when compiled for 32-bits, but not if you compile it for 64-bits. There are probably some issues with 64 bit pointers stored in 32-bit int and sqInt variables. If you can make some progress on this, it would be great :-)
Dave
Excellent.
thx.
tty
---- On Fri, 04 Apr 2014 05:29:25 -0700 David T. Lewis<lewis@mail.msen.com> wrote ----
On Thu, Apr 03, 2014 at 01:44:42PM -0700, gettimothy wrote: > > Howdy all. > > I will be debugging the SqueakSSL plugin on Linux tomorrow or so and am planning on using DDD to connect to a running process and see what I can see. >
Regarding the SqueakSSL plugin, there are two Mantis entries that you should read for background:
http://bugs.squeak.org/view.php?id=7751
http://bugs.squeak.org/view.php?id=7793
IIRC, the SqueakSSL plugin works when compiled for 32-bits, but not if you compile it for 64-bits. There are probably some issues with 64 bit pointers stored in 32-bit int and sqInt variables. If you can make some progress on this, it would be great :-)
Dave
On Thu, Apr 03, 2014 at 10:37:04AM -0700, Eliot Miranda wrote:
oops. they were in another package. done. thx!
Thanks Eliot, all is well again for building Cog starting from a clean Squeak image:
http://build.squeak.org/job/CogVM/
Dave
On Wed, Apr 2, 2014 at 5:31 PM, David T. Lewis lewis@mail.msen.com wrote:
On Wed, Apr 02, 2014 at 10:17:56PM +0000, commits@source.squeak.org wrote:
Eliot Miranda uploaded a new version of VMMaker to project VM Maker: http://source.squeak.org/VMMaker/VMMaker.oscog-eem.662.mcz
<bump>
Hi Eliot,
Don't forget to move #minLargeHeaderSize and #sizeHeader:putBodySize: into the VMMaker package next time you do a commit :-)
vm/vm.a(gcc3x-cointerp.o): In function `allInstancesOf': /var/lib/jenkins/workspace/CogVM/src/vm/gcc3x-cointerp.c:9592: undefined reference to `minLargeHeaderSize' /var/lib/jenkins/workspace/CogVM/src/vm/gcc3x-cointerp.c:9593: undefined reference to `sizeHeaderputBodySize' /var/lib/jenkins/workspace/CogVM/src/vm/gcc3x-cointerp.c:9664: undefined reference to `sizeHeaderputBodySize'
Thanks, Dave
-- best, Eliot
David,
is http://build.squeak.org/job/CogVM/546/ a daily build based off the work Eliot is doing each time he uploads an update?
How are the Jenkins build above and http://squeakvm.org/svn/squeak/branches/Cog/ related?
thx.
tty
On Thu, Apr 03, 2014 at 04:39:12PM -0700, gettimothy wrote:
David,
is http://build.squeak.org/job/CogVM/546/ a daily build based off the work Eliot is doing each time he uploads an update?
How are the Jenkins build above and http://squeakvm.org/svn/squeak/branches/Cog/ related?
The InterpreterVM and CogVM jobs that run on build.squeak.org are jobs that test the overall process of loading VMMaker and various related packages needed for generation of VM sources from Smalltalk source code (aka "slang"). The intent is to verify that the source packages are loadable into a clean Squeak image, and that they produce a coherent set of generated sources that can be used (along with the platform sources that are managed in Subversion) to compile a working VM.
It is necessary to run the compile step in order to ensure that the sources are really in good shape. For example, the compile step recently detected a couple of missing methods (the same ones that you had identified earlier by the way) in the oscog VMMaker package.
Assuming that the compile step is successful, the sources are assumed to be in good shape, and the resulting source code is saved as the outcome of the Jenkins test.
Dave
Thanks Dave.
What is the path of code..starting from Eliot uploads an update to Cog or VMMaker.oscog.
Does it look like this: Eliot->source.squeak.org/VMMaker->Jenkins->SVN
Or is it something else?
More importantly, is there someplace where this is documented?
thx
tty
---- On Thu, 03 Apr 2014 17:11:51 -0700 David T. Lewis<lewis@mail.msen.com> wrote ----
On Thu, Apr 03, 2014 at 04:39:12PM -0700, gettimothy wrote: > > David, > > is http://build.squeak.org/job/CogVM/546/ a daily build based off the work Eliot is doing each time he uploads an update? > > How are the Jenkins build above and http://squeakvm.org/svn/squeak/branches/Cog/ related? >
The InterpreterVM and CogVM jobs that run on build.squeak.org are jobs that test the overall process of loading VMMaker and various related packages needed for generation of VM sources from Smalltalk source code (aka "slang"). The intent is to verify that the source packages are loadable into a clean Squeak image, and that they produce a coherent set of generated sources that can be used (along with the platform sources that are managed in Subversion) to compile a working VM.
It is necessary to run the compile step in order to ensure that the sources are really in good shape. For example, the compile step recently detected a couple of missing methods (the same ones that you had identified earlier by the way) in the oscog VMMaker package.
Assuming that the compile step is successful, the sources are assumed to be in good shape, and the resulting source code is saved as the outcome of the Jenkins test.
Dave
On Thu, Apr 03, 2014 at 06:24:03PM -0700, gettimothy wrote:
Thanks Dave.
What is the path of code..starting from Eliot uploads an update to Cog or VMMaker.oscog.
Does it look like this: Eliot->source.squeak.org/VMMaker->Jenkins->SVN
No, the two Jenkins jobs are not a part of the VM development process, and they are not intended to produce VM source or executables for general distribution. They are just an automated check for the current health of the sources, and a check to make sure that someone who wants to build a VM can do so starting with a clean Squeak image.
Or is it something else?
More importantly, is there someplace where this is documented?
As far as the Jenkins jobs, I suppose that you can think of the scripts as a form of online documentation. I tried to make them as readable as I could, and you can open them in a workspace and evaluate them step by step.
The script for the interpreter VM is: http://build.squeak.org/job/InterpreterVM/ws/VMUnixBuild.st
The script for Cog is: http://build.squeak.org/job/CogVM/ws/VMCogUnixBuild.st
Dave
thx
tty
---- On Thu, 03 Apr 2014 17:11:51 -0700 David T. Lewis<lewis@mail.msen.com> wrote ----
On Thu, Apr 03, 2014 at 04:39:12PM -0700, gettimothy wrote: > > David, > > is http://build.squeak.org/job/CogVM/546/ a daily build based off the work Eliot is doing each time he uploads an update? > > How are the Jenkins build above and http://squeakvm.org/svn/squeak/branches/Cog/ related? >
The InterpreterVM and CogVM jobs that run on build.squeak.org are jobs that test the overall process of loading VMMaker and various related packages needed for generation of VM sources from Smalltalk source code (aka "slang"). The intent is to verify that the source packages are loadable into a clean Squeak image, and that they produce a coherent set of generated sources that can be used (along with the platform sources that are managed in Subversion) to compile a working VM.
It is necessary to run the compile step in order to ensure that the sources are really in good shape. For example, the compile step recently detected a couple of missing methods (the same ones that you had identified earlier by the way) in the oscog VMMaker package.
Assuming that the compile step is successful, the sources are assumed to be in good shape, and the resulting source code is saved as the outcome of the Jenkins test.
Dave
vm-dev@lists.squeakfoundation.org