[squeak-dev] How to find a CompiledBlock's parse node in a CompiledMethod's parse tree?
Eliot Miranda
eliot.miranda at gmail.com
Tue Dec 14 22:27:34 UTC 2021
On Tue, Dec 14, 2021 at 5:19 AM Marcel Taeumel <marcel.taeumel at hpi.de>
wrote:
> Hi all --
>
> Decompilation for instances of CompiledBlock is currently wrong. It just
> treats the CompiledMethod where the CompiledBlock is embedded.
>
Well, it's been that way for a long time and there's something to do with
method wrappers (see methodForDecompile) that I don't understand that makes
me leery of just changing this.
> Compare the following two examples:
>
> [3+4] method "i.e., compiledCode" decompile decompileString.
> [3+4] decompile decompileString.
>
> Well, first, the message #method on FullBlockClosure is misleading
> because we are looking for the compiled-code object, which is an instance
> of CompiledBlock here.
>
> Anyway, I then tried to understand how to make Decompiler >>
> decompileBlock: work for CompiledBlock and not just FullBlockClosure. It
> turns out, that there is no #pc set in any decompiled parse node.
>
> How to find a CompiledBlock's parse node in a CompiledMethod's parse tree?
>
See Decompiler>>decompileBlock:
| block |
block := [3+4].
block method decompileWithTemps nodesDo:
[:node| (node pc isVariableBinding and: [node pc key = block method])
ifTrue: [^node]]
=> {[3 + 4]}
i.e. the decompiler carefully sets the pc of a full block node to an
association so you can find the thing.
Now, as far as changing things to work the way you expect, I don't object,
provided you check out MethodWrappers, etc.
CompiledMethod>>methodForDecompile has my initials on it, but I didn't
write it. So what its comment means I don't know but we shoud find out
before we break things.
CompiledMethod>>methodForDecompile
"This is a hook to allow recursive methods like MwMethodWrapper to
avoid infinite recursion."
^self
I *really* don't like this method, but presumably it's there for a reason.
_,,,^..^,,,_
best, Eliot
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20211214/7f9a4775/attachment.html>
More information about the Squeak-dev
mailing list
|