[squeak-dev] debugging bug
eliot.miranda at gmail.com
Fri Aug 24 14:20:50 UTC 2018
> On Aug 23, 2018, at 7:58 PM, Bert Freudenberg <bert at freudenbergs.de> wrote:
>> On Thu, 23 Aug 2018 at 07:38, Eliot Miranda <eliot.miranda at gmail.com> wrote:
>> Hi Bert,
>>> On Wed, Aug 22, 2018 at 3:57 PM Bert Freudenberg <bert at freudenbergs.de> wrote:
>>>> On Mon, 20 Aug 2018 at 16:06, Chris Muller <asqueaker at gmail.com> wrote:
>>>> I would never have guessed that fix. It seems better, thanks. I
>>>> think the ifNil: check is not quite working, it seems to "stay" on the
>>>> assignment for two steps, then skips over the #ifNil: check.
>>>> It does now highlight the cases its checking, which is very nice.
>>> The debugger's highlighting is actually very simple: It looks up which parse node has the current context's pc, and uses the source map to find the interval (a.k.a. source range) in the source code to highlight.
>>> This information comes from the compiler. It's parsing the source code into a tree of parse nodes, while its encoder records their source range. Then the compiler traverses that tree to emit byte code, recording the pc in each node.
>>> To fix the highlighting we just need to ensure that when the debugger stops on a pc, that pc is actually found in the right parse node, and the node has the right source range associated.
>>> I was about to do a fix for ifNil etc. but I see Eliot beat me to it in Compiler-eem.391. That's a one-line fix too, the recorded pc was just too far ahead.
>> But the fix is incomplete. Replace ifNil: by an ifNil:ifNotNil: in Chris' example and one sees the same failure to emphasize anything for the == nil send hidden in the inlined ifNil:ifNotNil:
> That's because it fails to assign a source range to the hidden "== nil" message node.
> Fixed in Compiler-bf.393.
> There's still a minor glitch when the ifNotNil: block has an argument. In that case the compiler creates a hidden assignment node for the argument, but the debugger stops once on that assignment, and stops again on the "== nil" comparison. It really should jump over the assignment, but I'm not sure how to arrange that.
It can’t be fixed at the step level, which is checking willSend willReturn and willAssign. But it could be fixed in the Debugger itself *provided* source ranges are correct and reliable. If source ranges are correct then in step the Debugger can remember the current source range, ask the context to step, and if
- the next source range (& context) is the same
- willAssign was true and willSend is true and peeking for the selector answers #==. and top of stack is nil
then the Debugger itself can add the extra step
> - Bert -
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Squeak-dev