[squeak-dev] Question on DebuggerMethodMap

Eliot Miranda eliot.miranda at gmail.com
Mon Nov 22 05:29:53 UTC 2021


Hi Christoph,

On Fri, Nov 19, 2021 at 7:48 AM <christoph.thiede at student.hpi.uni-potsdam.de>
wrote:

> Hi there, hi Eliot,
>
> is there already a protocol or a variation of DebuggerMethodMap that
> accurately works for single byte codes? I.e., when an instruction pushes a
> variable on the stack, only the variable range is returned, or for a
> jumpIfTrue: instruction, only the ifTrue: is selected.
>

The mapping of source range to parse node is done in the compiler.  See
Encoder>>#noteSourceRange:forNode: and senders.  Then bytecodes are
associated with source ranges when bytecode is generated.  First a node is
assigned a pc in either emitCodeForEffect:encoder:
or emitCodeForValue:encoder: (see assignments to ParseNode's pc instance
variable).  Then the chain is from pc to node to source range by following
the chain from pc to node with that pc.  Another important part is that the
debugger only pauses execution at specific points (assignments, sends and
returns).  The compiler generates source ranges only for those bytecodes
the debugger stops execution at.

DebuggerMethidMap solves a different problem.  It determines what temporary
variables are live at each point in a method and its constituent blocks.
The closure implementation, with its copying of values and its use of
indirection vectors, means a temporary name maps to different locations at
different points in a method.

You will notice that the debugger's highlighting and stepping is
occasionally incorrect through inlined forms (ifNotNil: and to:do:).  It
would be great to see this fixed properly.

Is there already any approach to do this or would I need to build this
> myself first? :-)
>

First you should specify the behaviour you want before seeing whether you
will be able to extend the existing mechanism or build a new one.

Best,
> Christoph
>

_,,,^..^,,,_
best, Eliot
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20211121/a6c3b0bc/attachment.html>


More information about the Squeak-dev mailing list