<div dir="ltr"><div dir="ltr"><div class="gmail_default" style="font-size:small">Hi Christoph,<br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Fri, Nov 19, 2021 at 7:48 AM <<a href="mailto:christoph.thiede@student.hpi.uni-potsdam.de">christoph.thiede@student.hpi.uni-potsdam.de</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex">Hi there, hi Eliot,<br>
<br>
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.<br></blockquote><div><br></div><div class="gmail_default" style="font-size:small">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.</div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">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.</div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">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.</div><div class="gmail_default" style="font-size:small"><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex">Is there already any approach to do this or would I need to build this myself first? :-)<br></blockquote><div><br></div><div class="gmail_default" style="font-size:small">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.</div><div class="gmail_default" style="font-size:small"><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex">Best,<br>
Christoph<br></blockquote></div><br><div dir="ltr" class="gmail_signature"><div dir="ltr"><div><span style="font-size:small;border-collapse:separate"><div>_,,,^..^,,,_<br></div><div>best, Eliot</div></span></div></div></div></div>