Hi David,
sorry for dropping this and not having time to put more work into it. You're right, this will get confusing.
Right now the Spur format tracer can trace Spur format images to Spur. Those will load on a Spur VM. I have (locally, or maybe I also pushed it) code to also trace V3 images to Spur, and those won't load on Spur VMs, but they do load on RSqueak, which was one of my use cases.
Marcel Taeumel and I were discussing where to go with this and that it might be useful to have support through the SystemTracing package for cross-tracing images between different formats. Imagine that you are working on a 64-bit Sista-enabled VM on your x86 machine and you want to move to (maybe) and older 32-bit ARM system without a Sista VM or to SqueakJS which doesn't support Spur (yet): We'd like the "Save As.." dialog to offer the choice of word size and format as well, and use the SystemTracing package to convert between the formats. This might also be useful to convert the Etoys images into the newer format without losing the in-image content and then using RSqueak or something to do the necessary adjustments to get it to load on the Spur VMs.
I will get back to this soon, I hope, but it will be a couple more weeks before I have time again. Is that alright to leave it be until then?
Best, Tim
David T. Lewis wrote
Hi Tim,
The latest version of your system tracer for Spur (on squeaksource) is in SystemTracing-tfel.41. The SystemTracerSpur class would benefit from a class comment to explain with it can (and cannot) do. Would you mind adding a comment to clarify?
My understanding is that SystemTracerSpur traces a 32-bit V3 image to 32-bit Spur, although it is not clear if the traced image can then be run under a Spur VM (I suspect not, but I am not sure). We also have 64-bit Spur images available, and these will require tracing support either with SystemTracer, or using the VMMaker tracing that Eliot has already provided. So I think that this might get confusing soon, and a class comment will help to explain it.
Thanks!
Dave
On Fri, Feb 26, 2016 at 07:59:04AM -0800, timfelgentreff wrote:
I've updated the SystemTracer package to trace a Spur-format image.
This works as far as I can tell, producing a header that looks just like the header produced by the VM and the objects written also look good. I can also open the image in RSqueak, but not on Spur. It crashes immediately and produces a Smalltalk backtrace that looks like it never manages to return from the image-saving method (but the names in the Stack-trace all look ok, leading me to believe that enough objects got written ok to figure out classes, method names, find the right Process to run and so forth).
Curiously, the old SystemTracer2 class that writes Cog-format images also produces images that cannot be opened by Cog VMs, only Interpreter VMs. So I assume there are other assumptions that maybe the JIT makes when starting up.
So my question is, what assumptions could there be, and where could I start looking.
Cheers, Tim
(If you're wondering why I'm using the Smalltalk-level tracing at all - in our quest to create (with RSqueakVM) a Squeak VM that runs Squeak code fast enough that we no longer have to rely on C code from plugins or optional primitives, we're trying to see how far we can push this, and e.g. write the image from within itself, too.)
-- View this message in context: http://forum.world.st/Tracing-a-Spur-Image-from-Smalltalk-tp4881224.html Sent from the Squeak VM mailing list archive at Nabble.com.
-- View this message in context: http://forum.world.st/Tracing-a-Spur-Image-from-Smalltalk-tp4881224p4899020.... Sent from the Squeak VM mailing list archive at Nabble.com.