[Vm-dev] Has anyone done a tutorial on...

Phil B pbpublist at gmail.com
Wed Sep 20 23:28:57 UTC 2017


Clément,

On Sep 20, 2017 7:04 PM, "Clément Bera" <bera.clement at gmail.com> wrote:


In practice, all the people using the simulator have images that were built
when Eliot's script was working, and we update the image with the new
VMMaker code but don't rebuild them. I know its not good but we had to keep
things working with limited ressources.


Well that explains a whole lot right there.  I fairly regularly rebuild my
images from scratch (too many bad experiences with image drift using
deltas) and get concerned when I can't do so.  I guess I'll not worry about
VMMaker for a while on that front if it's a known issue.


So there are 2 solutions:
- you ask someone with a working image to give it to you and you start from
there (by loading the most recent code, etc.).
- you fix Eliot's script or you bug him until he fixes it.


I actually have a 5.0-based VMMaker image so I guess I'll try updating
(ugh... 😀) it.  Since I'm only a casual viewer/user of these scripts, I'll
defer to others who know how they want things to work to update it rather
than potentially creating more work for them.



I read quickly your report but it looks to me that 1 can be debugged
through the simulator while 2,3,4 needs to be debugged with gdb. I am not
sure with 3 since Eliot added some simulation support for sockets at some
points.


Thanks, I'll try as you suggest.


For gdb with the VM the main things to know are:
- Debug VM is very slow, Assert VM is half the perf of prod VM for most
things (though stack page switch for example is much slower in Assert VM).
- in general you want an assert or debug VM and put a breakpoint on
warning, so when an assertion fails gdb stops and you can try to figure
things out.
- you need to compile the debug VM to access C variables if you need so.
- you can call debug functions printStackAllStack, printFrame,
printCogMethod, etc. in gdb. You can try to look in Slang in the VMMaker
code for the list of debug functions available (<api> pragma). You often
need to manually cast parameters to usqint / sqint in gdb to correctly call
those functions.


This is a place I've been running into trouble: I've browsed the print*
functions and have naively been trying to poke around but it's been a
slog.  Hopefully, the pointers you and the others have provided will help
me get moving a bit faster.


As always for simulator or gdb the best is to save an image about to crash,
start it on the debug platform and make it crash.

Good luck and have fun.


Thanks,
Phil



Thanks,
> Phil
>
>
>> Thanks,
>> Phil
>>
>> On Sep 18, 2017 7:38 PM, "tim Rowledge" <tim at rowledge.org> wrote:
>>
>>
>> When possible you’re much better off using the VMSimulator to examine an
>> image.
>>
>> > On 18-09-2017, at 4:25 PM, Phil B <pbpublist at gmail.com> wrote:
>> >
>> > Using gdb to explore a running image?  Blog post or video format is
>> great.  Most of what I've run across is related to the internals of the VM
>> rather than debugging an image.  My gdb skills are pretty rusty plus I
>> suspect that not knowing all of the helper functions available in the VM
>> (and how to best use them in a debugging workflow) is slowing me down.
>>
>>
>> tim
>> --
>> tim Rowledge; tim at rowledge.org; http://www.rowledge.org/tim
>> "Bother" said Pooh, as his rucksack opened whilst skydiving
>>
>>
>>
>>
>>
>
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.squeakfoundation.org/pipermail/vm-dev/attachments/20170920/7363e1ab/attachment.html>


More information about the Vm-dev mailing list