[Vm-dev] Shape/ABI of code jitted by cog?

[Eliot Miranda]

Hi Javier,

> On Feb 14, 2018, at 5:32 PM, Javier Pimás <elpochodelagente at gmail.com> wrote:
> 
> I've been debugging squeaknos running (crashing) inside a system vm. I think the simulator cannot be used in this case so I guess my next best choice will be a gdb debug stub.

That's an interesting question.  I think both approaches can help.  But I would defend burley start with the simulator:

The simulator goes to some effort to make sure that jitted code is run under similar constraints during simulation as it does in the real system.  When a call is made into the runtime (the rest of the interpreter) registers are smashed according to the ABI's caller & caller saved register conventions.  All variables outside of machine code that are accessed from machine code are given illegal addresses so that the machine code sequence that accesses them is the same as in the real system but causes an access violation and an exception handler handles the trap, looking up the illegal address in a mapping dictionary.

So you could add to the simulator a simulation of a hardware interrupt and see that the system could respond correctly while executing machine code.  Further, the simulator allows one to single step machine code so you could test that the system can handle a hardware interrupt at every instruction during the execution of some code, instead of simply interrupting at random and trying to fix isolated cases.

So yes, I would definitely start with the simulator.  I wouldn't waste my time debugging the real system until I'd demonstrated to myself that simulated hardware interrupts can be handled reliably during a broad range of execution, say every instruction during the bootstrap of a small image.

HTH

and this is really exciting!  It'll be fantastic to have SqueakNOS and Spur and Cog working together.

> Cheers!
> 
>> On Wed, Feb 14, 2018 at 3:26 PM, Eliot Miranda <eliot.miranda at gmail.com> wrote:
>>  
>> Hi Javier,
>> 
>>> On Wed, Feb 14, 2018 at 6:32 AM, Javier Pimás <elpochodelagente at gmail.com> wrote:
>>>  
>>> For debugging aid, I'd like to know if there is any cheatsheet with things like frame layout in the native stack (offset of the compiled method, the receiver, temporaries) and shape of the code (i.e. how to detect where a method starts and ends). 
>> 
>> The first choice is how you're going to debug. You can debug the generated C code.  There are several printing and debug functions included in the generated source, and it is set up to be compiled in three variants, production, assert and debug.  See any of the HowToBuild files under the build directories.  But debugging at the C level is much more difficult and less productive than using the development environment, "the simulator".
>> 
>> The VM is best understood, developed and debugged in Smalltalk.  You can create a VMMaker image containing the full environment using the image/buildspurtrunkvmmaker[64]image.sh scripts (32-bit or 64-bit, 64-bit is faster for 64-bit development).  A workspace in the image (the contents of image/VM Simulation Workspace.text) contains launch expressions for the simulator.  The simulator has three windows, the top for the Smalltalk display, the bottom left for a transcript, and the bottom right for commands.  The bottom right pane has a menu with an extensive set of debug commands.
>> 
>> One useful thing is to browse all methods beginning with print local to VMMaker, especially those in the Cogit hierarchy (the JIT), the StackInterpreter hierarchy (the Interpreter) and the SpurMemoryManager hierarchy (the memory manager/GC).
>> 
>> Perhaps you could tell us a little bit about what you're trying to do and we can try and provide some more specific information.
>> 
>>> Cheers,
>>> Pocho
>>> 
>>> -- 
>>> Javier Pimás
>>> Ciudad de Buenos Aires
>> 
>> _,,,^..^,,,_
>> best, Eliot
> -- 
> Javier Pimás
> Ciudad de Buenos Aires
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.squeakfoundation.org/pipermail/vm-dev/attachments/20180215/7cd61624/attachment.html>