Shape/ABI of code jitted by cog?

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
7 messages Options
Reply | Threaded
Open this post in threaded view
|

Shape/ABI of code jitted by cog?

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

Cheers,
Pocho

--
Javier Pimás
Ciudad de Buenos Aires
Reply | Threaded
Open this post in threaded view
|

Re: Shape/ABI of code jitted by cog?

Clément Béra
 
Hi Javier,

Frame layout: See CoInterpreter>>initializeFrameIndices method code and comment which describe frame layout and provide correct indices.

Shape of the code: I assume you're talking about shape of machine code version of methods/blocks. This is described in the CogMethod class comment. 

To detect where a method starts and ends:
- the compiled method / compiled block in the heap has a pointer to the cog method in the code zone.
- from the cog method pointer, you've got a fixed offset to the entries to start executing machine code. See entryOffset / noCheckEntryOffset instance variables in Cogit class comment, note that in 32 bits I believe there's a jump back for Smi/Char in the entries so executable code actually starts before the entry and there's no reference to exactly where it starts (we have references only to places that can be called).
- from the cog method pointer, you can read in the header the block size to know where executable code stops and map for mcpc - bcpc debugging starts (See Cogit>>mapStartFor:, executable ends at cog method pointer + block size - 1)

Have fun :-)

On Wed, Feb 14, 2018 at 3:32 PM, Javier Pimás <[hidden email]> 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). 

Cheers,
Pocho

--
Javier Pimás
Ciudad de Buenos Aires




--
Clément Béra
Pharo consortium engineer
Bâtiment B 40, avenue Halley 59650 Villeneuve d'Ascq
Reply | Threaded
Open this post in threaded view
|

Re: Shape/ABI of code jitted by cog?

Clément Béra
 
I've just seen that the title said ABI for code jitted by Cog.

The Smalltalk-to-Smalltalk calling convention is described in StackToRegisterMappingCogit class>>callingConvention method comment. Calls to C use standard OS/Processor dependent calling conventions through the trampolines (routines performing stack switch, potential register saves, etc.). Calls from C to jitted code go through enilopmarts (trampolines written backwards, opposite of trampoline behavior)

On Wed, Feb 14, 2018 at 4:07 PM, Clément Bera <[hidden email]> wrote:
Hi Javier,

Frame layout: See CoInterpreter>>initializeFrameIndices method code and comment which describe frame layout and provide correct indices.

Shape of the code: I assume you're talking about shape of machine code version of methods/blocks. This is described in the CogMethod class comment. 

To detect where a method starts and ends:
- the compiled method / compiled block in the heap has a pointer to the cog method in the code zone.
- from the cog method pointer, you've got a fixed offset to the entries to start executing machine code. See entryOffset / noCheckEntryOffset instance variables in Cogit class comment, note that in 32 bits I believe there's a jump back for Smi/Char in the entries so executable code actually starts before the entry and there's no reference to exactly where it starts (we have references only to places that can be called).
- from the cog method pointer, you can read in the header the block size to know where executable code stops and map for mcpc - bcpc debugging starts (See Cogit>>mapStartFor:, executable ends at cog method pointer + block size - 1)

Have fun :-)

On Wed, Feb 14, 2018 at 3:32 PM, Javier Pimás <[hidden email]> 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). 

Cheers,
Pocho

--
Javier Pimás
Ciudad de Buenos Aires




--
Clément Béra
Pharo consortium engineer
Bâtiment B 40, avenue Halley 59650 Villeneuve d'Ascq



--
Clément Béra
Pharo consortium engineer
Bâtiment B 40, avenue Halley 59650 Villeneuve d'Ascq
Reply | Threaded
Open this post in threaded view
|

Re: Shape/ABI of code jitted by cog?

melkyades
 
 Great! I'll have a look at all this and ask for more info if needed, thanks!

On Wed, Feb 14, 2018 at 12:11 PM, Clément Bera <[hidden email]> wrote:
 
I've just seen that the title said ABI for code jitted by Cog.

The Smalltalk-to-Smalltalk calling convention is described in StackToRegisterMappingCogit class>>callingConvention method comment. Calls to C use standard OS/Processor dependent calling conventions through the trampolines (routines performing stack switch, potential register saves, etc.). Calls from C to jitted code go through enilopmarts (trampolines written backwards, opposite of trampoline behavior)

On Wed, Feb 14, 2018 at 4:07 PM, Clément Bera <[hidden email]> wrote:
Hi Javier,

Frame layout: See CoInterpreter>>initializeFrameIndices method code and comment which describe frame layout and provide correct indices.

Shape of the code: I assume you're talking about shape of machine code version of methods/blocks. This is described in the CogMethod class comment. 

To detect where a method starts and ends:
- the compiled method / compiled block in the heap has a pointer to the cog method in the code zone.
- from the cog method pointer, you've got a fixed offset to the entries to start executing machine code. See entryOffset / noCheckEntryOffset instance variables in Cogit class comment, note that in 32 bits I believe there's a jump back for Smi/Char in the entries so executable code actually starts before the entry and there's no reference to exactly where it starts (we have references only to places that can be called).
- from the cog method pointer, you can read in the header the block size to know where executable code stops and map for mcpc - bcpc debugging starts (See Cogit>>mapStartFor:, executable ends at cog method pointer + block size - 1)

Have fun :-)

On Wed, Feb 14, 2018 at 3:32 PM, Javier Pimás <[hidden email]> 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). 

Cheers,
Pocho

--
Javier Pimás
Ciudad de Buenos Aires




--
Clément Béra
Pharo consortium engineer
Bâtiment B 40, avenue Halley 59650 Villeneuve d'Ascq



--
Clément Béra
Pharo consortium engineer
Bâtiment B 40, avenue Halley 59650 Villeneuve d'Ascq




--
Javier Pimás
Ciudad de Buenos Aires
Reply | Threaded
Open this post in threaded view
|

Re: Shape/ABI of code jitted by cog?

Eliot Miranda-2
In reply to this post by melkyades
 
Hi Javier,

On Wed, Feb 14, 2018 at 6:32 AM, Javier Pimás <[hidden email]> 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
Reply | Threaded
Open this post in threaded view
|

Re: Shape/ABI of code jitted by cog?

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

Cheers!

On Wed, Feb 14, 2018 at 3:26 PM, Eliot Miranda <[hidden email]> wrote:
 
Hi Javier,

On Wed, Feb 14, 2018 at 6:32 AM, Javier Pimás <[hidden email]> 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
Reply | Threaded
Open this post in threaded view
|

Re: Shape/ABI of code jitted by cog?

Eliot Miranda-2
 
Hi Javier,

On Feb 14, 2018, at 5:32 PM, Javier Pimás <[hidden email]> 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 <[hidden email]> wrote:
 
Hi Javier,

On Wed, Feb 14, 2018 at 6:32 AM, Javier Pimás <[hidden email]> 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