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

Ben Coman btc at openinworld.com
Thu Sep 21 15:37:54 UTC 2017


On Thu, Sep 21, 2017 at 7:28 AM, Phil B <pbpublist at gmail.com> wrote:

>
> 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.
>

Maybe useful...
http://forum.world.st/reversible-debugging-with-gdb-td4960462.html

cheers -ben


> 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/20170921/53cfb0f1/attachment-0001.html>


More information about the Vm-dev mailing list