Decompilation problem

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

Decompilation problem

Yoshiki Ohshima-3
I noticed that when I debug grammar written in OMeta2/Squeak, there is
a problem with some particular methods.  For example, I load
OMeta2-preload and -postload, and do:

               (OMeta2 compiledMethodAt: #token) decompileWithTemps

I get something like:
------------------------------------
 token
        | t |
        ^ true
                ifTrue: [_r1 := self apply: #anything.
                        self apply: #spaces.
                        self apply: #seq withArgs: {_r1}]
------------------------------------
Debugger uses this to obtain the source code and then it trys to parse
it to get the source map. But "_r1" is not a valid variable name so
this process fails.

It appears that the underscore is originated from the method:
------------------------------------
codeRemoteTemp: index remoteTemps: tempVector

        ^(RemoteTempVectorNode new
                name: '_r', index printString
                index: index
                type: LdTempType
                scope: 0)
                        remoteTemps: tempVector;
                        yourself
------------------------------------
But I cannot tell why it is "leaking out" to the final result.  Does
anybody know what is going on?

-- Yoshiki

Reply | Threaded
Open this post in threaded view
|

Re: Decompilation problem

Eliot Miranda-2
Hi Yoshiki,

    what's the image you're using, or at least what is it derived from?  Also, what's the result of (OMeta2 >> #token) symbolic ?

On Thu, Apr 12, 2012 at 3:09 PM, Yoshiki Ohshima <[hidden email]> wrote:
I noticed that when I debug grammar written in OMeta2/Squeak, there is
a problem with some particular methods.  For example, I load
OMeta2-preload and -postload, and do:

              (OMeta2 compiledMethodAt: #token) decompileWithTemps

I get something like:
------------------------------------
 token
       | t |
       ^ true
               ifTrue: [_r1 := self apply: #anything.
                       self apply: #spaces.
                       self apply: #seq withArgs: {_r1}]
------------------------------------
Debugger uses this to obtain the source code and then it trys to parse
it to get the source map. But "_r1" is not a valid variable name so
this process fails.

It appears that the underscore is originated from the method:
------------------------------------
codeRemoteTemp: index remoteTemps: tempVector

       ^(RemoteTempVectorNode new
               name: '_r', index printString
               index: index
               type: LdTempType
               scope: 0)
                       remoteTemps: tempVector;
                       yourself
------------------------------------
But I cannot tell why it is "leaking out" to the final result.  Does
anybody know what is going on?

-- Yoshiki




--
best,
Eliot



Reply | Threaded
Open this post in threaded view
|

Re: Decompilation problem

Yoshiki Ohshima-3
At Thu, 12 Apr 2012 16:08:53 -0700,
Eliot Miranda wrote:
>
> Hi Yoshiki,
>
>     what's the image you're using, or at least what is it derived from?  Also, what's the result of (OMeta2 >> #token) symbolic ?

The image is one started from "Squeak4.3alpha-11481" and updated by
pressing the "update code from server" button.  The result of
#symbolic is like this:

37 <71> pushConstant: true
38 <AC 0F> jumpFalse: 55
40 <70> self
41 <21> pushConstant: #anything
42 <E0> send: apply:
43 <68> popIntoTemp: 0
44 <70> self
45 <22> pushConstant: #spaces
46 <E0> send: apply:
47 <87> pop
48 <70> self
49 <24> pushConstant: #seq
50 <10> pushTemp: 0
51 <8A 81> pop 1 into (Array new: 1)
53 <F3> send: apply:withArgs:
54 <90> jumpTo: 56
55 <73> pushConstant: nil
56 <7C> returnTop

-- Yoshiki


>
> On Thu, Apr 12, 2012 at 3:09 PM, Yoshiki Ohshima <[hidden email]> wrote:
>
>     I noticed that when I debug grammar written in OMeta2/Squeak, there is
>     a problem with some particular methods.  For example, I load
>     OMeta2-preload and -postload, and do:
>    
>                   (OMeta2 compiledMethodAt: #token) decompileWithTemps
>    
>     I get something like:
>     ------------------------------------
>      token
>            | t |
>            ^ true
>                    ifTrue: [_r1 := self apply: #anything.
>                            self apply: #spaces.
>                            self apply: #seq withArgs: {_r1}]
>     ------------------------------------
>     Debugger uses this to obtain the source code and then it trys to parse
>     it to get the source map. But "_r1" is not a valid variable name so
>     this process fails.
>    
>     It appears that the underscore is originated from the method:
>     ------------------------------------
>     codeRemoteTemp: index remoteTemps: tempVector
>    
>            ^(RemoteTempVectorNode new
>                    name: '_r', index printString
>                    index: index
>                    type: LdTempType
>                    scope: 0)
>                            remoteTemps: tempVector;
>                            yourself
>     ------------------------------------
>     But I cannot tell why it is "leaking out" to the final result.  Does
>     anybody know what is going on?
>    
>     -- Yoshiki
>
> --
> best,
> Eliot
>
>
> [2  <text/plain; us-ascii (7bit)>]
>

Reply | Threaded
Open this post in threaded view
|

Re: Decompilation problem

Eliot Miranda-2
Hi Yoshiki,

On Thu, Apr 12, 2012 at 4:27 PM, Yoshiki Ohshima <[hidden email]> wrote:
At Thu, 12 Apr 2012 16:08:53 -0700,
Eliot Miranda wrote:
>
> Hi Yoshiki,
>
>     what's the image you're using, or at least what is it derived from?  Also, what's the result of (OMeta2 >> #token) symbolic ?

The image is one started from "Squeak4.3alpha-11481" and updated by
pressing the "update code from server" button.  The result of
#symbolic is like this:

37 <71> pushConstant: true
38 <AC 0F> jumpFalse: 55
40 <70> self
41 <21> pushConstant: #anything
42 <E0> send: apply:
43 <68> popIntoTemp: 0
44 <70> self
45 <22> pushConstant: #spaces
46 <E0> send: apply:
47 <87> pop
48 <70> self
49 <24> pushConstant: #seq
50 <10> pushTemp: 0
51 <8A 81> pop 1 into (Array new: 1)
53 <F3> send: apply:withArgs:
54 <90> jumpTo: 56
55 <73> pushConstant: nil
56 <7C> returnTop

-- Yoshiki

I can't reproduce this.  When I debug the following doit (which mimics your code) and inspect the context  I get a valid decompilation:

| t |
       ^ true
               ifTrue: [t := self apply: #anything.
                       self apply: #spaces.
                       self apply: #seq withArgs: {t}]

the same code:

method symbolic
'37 <71> pushConstant: true
38 <AC 0F> jumpFalse: 55
40 <70> self
41 <21> pushConstant: #anything
42 <E0> send: apply:
43 <68> popIntoTemp: 0
44 <70> self
45 <22> pushConstant: #spaces
46 <E0> send: apply:
47 <87> pop
48 <70> self
49 <24> pushConstant: #seq
50 <10> pushTemp: 0
51 <8A 81> pop 1 into (Array new: 1)
53 <F3> send: apply:withArgs:
54 <90> jumpTo: 56
55 <73> pushConstant: nil
56 <7C> returnTop
'

and decompileWithTemps returns something correct:

method decompileWithTemps
DoIt
| t |
^ true
ifTrue: [t := self apply: #anything.
self apply: #spaces.
self apply: #seq withArgs: {t}] 

So has OMeta patched some old bug in the decompiler which is now obsoleted by some other fix?



>
> On Thu, Apr 12, 2012 at 3:09 PM, Yoshiki Ohshima <[hidden email]> wrote:
>
>     I noticed that when I debug grammar written in OMeta2/Squeak, there is
>     a problem with some particular methods.  For example, I load
>     OMeta2-preload and -postload, and do:
>
>                   (OMeta2 compiledMethodAt: #token) decompileWithTemps
>
>     I get something like:
>     ------------------------------------
>      token
>            | t |
>            ^ true
>                    ifTrue: [_r1 := self apply: #anything.
>                            self apply: #spaces.
>                            self apply: #seq withArgs: {_r1}]
>     ------------------------------------
>     Debugger uses this to obtain the source code and then it trys to parse
>     it to get the source map. But "_r1" is not a valid variable name so
>     this process fails.
>
>     It appears that the underscore is originated from the method:
>     ------------------------------------
>     codeRemoteTemp: index remoteTemps: tempVector
>
>            ^(RemoteTempVectorNode new
>                    name: '_r', index printString
>                    index: index
>                    type: LdTempType
>                    scope: 0)
>                            remoteTemps: tempVector;
>                            yourself
>     ------------------------------------
>     But I cannot tell why it is "leaking out" to the final result.  Does
>     anybody know what is going on?
>
>     -- Yoshiki
>
> --
> best,
> Eliot
>
>
> [2  <text/plain; us-ascii (7bit)>]
>




--
best,
Eliot



Reply | Threaded
Open this post in threaded view
|

Re: Decompilation problem

Bert Freudenberg

On 12.04.2012, at 16:40, Eliot Miranda wrote:

Hi Yoshiki,

On Thu, Apr 12, 2012 at 4:27 PM, Yoshiki Ohshima <[hidden email]> wrote:
At Thu, 12 Apr 2012 16:08:53 -0700,
Eliot Miranda wrote:
>
> Hi Yoshiki,
>
>     what's the image you're using, or at least what is it derived from?  Also, what's the result of (OMeta2 >> #token) symbolic ?

The image is one started from "Squeak4.3alpha-11481" and updated by
pressing the "update code from server" button.  The result of
#symbolic is like this:

37 <71> pushConstant: true
38 <AC 0F> jumpFalse: 55
40 <70> self
41 <21> pushConstant: #anything
42 <E0> send: apply:
43 <68> popIntoTemp: 0
44 <70> self
45 <22> pushConstant: #spaces
46 <E0> send: apply:
47 <87> pop
48 <70> self
49 <24> pushConstant: #seq
50 <10> pushTemp: 0
51 <8A 81> pop 1 into (Array new: 1)
53 <F3> send: apply:withArgs:
54 <90> jumpTo: 56
55 <73> pushConstant: nil
56 <7C> returnTop

-- Yoshiki

I can't reproduce this.  When I debug the following doit (which mimics your code) and inspect the context  I get a valid decompilation:

| t |
       ^ true
               ifTrue: [t := self apply: #anything.
                       self apply: #spaces.
                       self apply: #seq withArgs: {t}]

the same code:

method symbolic
'37 <71> pushConstant: true
38 <AC 0F> jumpFalse: 55
40 <70> self
41 <21> pushConstant: #anything
42 <E0> send: apply:
43 <68> popIntoTemp: 0
44 <70> self
45 <22> pushConstant: #spaces
46 <E0> send: apply:
47 <87> pop
48 <70> self
49 <24> pushConstant: #seq
50 <10> pushTemp: 0
51 <8A 81> pop 1 into (Array new: 1)
53 <F3> send: apply:withArgs:
54 <90> jumpTo: 56
55 <73> pushConstant: nil
56 <7C> returnTop
'

and decompileWithTemps returns something correct:

method decompileWithTemps
DoIt
| t |
^ true
ifTrue: [t := self apply: #anything.
self apply: #spaces.
self apply: #seq withArgs: {t}] 

So has OMeta patched some old bug in the decompiler which is now obsoleted by some other fix?

The difference appears to be that the OMeta compiler answers '(t)[(t)[(t)]]' for the schematicTempNamesString. The regular compiler answers 't'. This trips the Decompiler over.

- Bert -




Reply | Threaded
Open this post in threaded view
|

Re: Decompilation problem

Yoshiki Ohshima-3
In reply to this post by Eliot Miranda-2
At Thu, 12 Apr 2012 16:40:27 -0700,
Eliot Miranda wrote:

>
> Hi Yoshiki,
>
> On Thu, Apr 12, 2012 at 4:27 PM, Yoshiki Ohshima <[hidden email]> wrote:
>
>     At Thu, 12 Apr 2012 16:08:53 -0700,
>     Eliot Miranda wrote:
>     >
>     > Hi Yoshiki,
>     >
>     >     what's the image you're using, or at least what is it derived from?  Also, what's the result of (OMeta2 >> #token) symbolic ?
>    
>     The image is one started from "Squeak4.3alpha-11481" and updated by
>     pressing the "update code from server" button.  The result of
>     #symbolic is like this:
>    
>     37 <71> pushConstant: true
>     38 <AC 0F> jumpFalse: 55
>     40 <70> self
>     41 <21> pushConstant: #anything
>     42 <E0> send: apply:
>     43 <68> popIntoTemp: 0
>     44 <70> self
>     45 <22> pushConstant: #spaces
>     46 <E0> send: apply:
>     47 <87> pop
>     48 <70> self
>     49 <24> pushConstant: #seq
>     50 <10> pushTemp: 0
>     51 <8A 81> pop 1 into (Array new: 1)
>     53 <F3> send: apply:withArgs:
>     54 <90> jumpTo: 56
>     55 <73> pushConstant: nil
>     56 <7C> returnTop
>    
>     -- Yoshiki
>
> I can't reproduce this.  When I debug the following doit (which mimics your code) and inspect the context  I get a valid decompilation:
>
> | t |
>        ^ true
>                ifTrue: [t := self apply: #anything.
>                        self apply: #spaces.
>                        self apply: #seq withArgs: {t}]
>
> the same code:
>
> method symbolic
> '37 <71> pushConstant: true
> 38 <AC 0F> jumpFalse: 55
> 40 <70> self
> 41 <21> pushConstant: #anything
> 42 <E0> send: apply:
> 43 <68> popIntoTemp: 0
> 44 <70> self
> 45 <22> pushConstant: #spaces
> 46 <E0> send: apply:
> 47 <87> pop
> 48 <70> self
> 49 <24> pushConstant: #seq
> 50 <10> pushTemp: 0
> 51 <8A 81> pop 1 into (Array new: 1)
> 53 <F3> send: apply:withArgs:
> 54 <90> jumpTo: 56
> 55 <73> pushConstant: nil
> 56 <7C> returnTop
> '
>
> and decompileWithTemps returns something correct:
>
> method decompileWithTemps
> DoIt
> | t |
> ^ true
> ifTrue: [t := self apply: #anything.
> self apply: #spaces.
> self apply: #seq withArgs: {t}] 
>
> So has OMeta patched some old bug in the decompiler which is now obsoleted by some other fix?

It does go through different code path when decompiling as the
regular Parser is used for the first attempts to decompile the code
in OMeta syntax, and fall back.  It is likely that it is
over-compensating something, but it is hard to nail down...

-- Yoshiki

>     > On Thu, Apr 12, 2012 at 3:09 PM, Yoshiki Ohshima <[hidden email]> wrote:
>     >
>     >     I noticed that when I debug grammar written in OMeta2/Squeak, there is
>     >     a problem with some particular methods.  For example, I load
>     >     OMeta2-preload and -postload, and do:
>     >
>     >                   (OMeta2 compiledMethodAt: #token) decompileWithTemps
>     >
>     >     I get something like:
>     >     ------------------------------------
>     >      token
>     >            | t |
>     >            ^ true
>     >                    ifTrue: [_r1 := self apply: #anything.
>     >                            self apply: #spaces.
>     >                            self apply: #seq withArgs: {_r1}]
>     >     ------------------------------------
>     >     Debugger uses this to obtain the source code and then it trys to parse
>     >     it to get the source map. But "_r1" is not a valid variable name so
>     >     this process fails.
>     >
>     >     It appears that the underscore is originated from the method:
>     >     ------------------------------------
>     >     codeRemoteTemp: index remoteTemps: tempVector
>     >
>     >            ^(RemoteTempVectorNode new
>     >                    name: '_r', index printString
>     >                    index: index
>     >                    type: LdTempType
>     >                    scope: 0)
>     >                            remoteTemps: tempVector;
>     >                            yourself
>     >     ------------------------------------
>     >     But I cannot tell why it is "leaking out" to the final result.  Does
>     >     anybody know what is going on?
>     >
>     >     -- Yoshiki
>     >
>     > --
>     > best,
>     > Eliot
>     >
>     >
>     > [2  <text/plain; us-ascii (7bit)>]
>     >
>
> --
> best,
> Eliot
>
>
> [2  <text/plain; us-ascii (7bit)>]
>

Reply | Threaded
Open this post in threaded view
|

Re: Decompilation problem

Eliot Miranda-2
In reply to this post by Bert Freudenberg


On Thu, Apr 12, 2012 at 5:51 PM, Bert Freudenberg <[hidden email]> wrote:

On 12.04.2012, at 16:40, Eliot Miranda wrote:

Hi Yoshiki,

On Thu, Apr 12, 2012 at 4:27 PM, Yoshiki Ohshima <[hidden email]> wrote:
At Thu, 12 Apr 2012 16:08:53 -0700,
Eliot Miranda wrote:
>
> Hi Yoshiki,
>
>     what's the image you're using, or at least what is it derived from?  Also, what's the result of (OMeta2 >> #token) symbolic ?

The image is one started from "Squeak4.3alpha-11481" and updated by
pressing the "update code from server" button.  The result of
#symbolic is like this:

37 <71> pushConstant: true
38 <AC 0F> jumpFalse: 55
40 <70> self
41 <21> pushConstant: #anything
42 <E0> send: apply:
43 <68> popIntoTemp: 0
44 <70> self
45 <22> pushConstant: #spaces
46 <E0> send: apply:
47 <87> pop
48 <70> self
49 <24> pushConstant: #seq
50 <10> pushTemp: 0
51 <8A 81> pop 1 into (Array new: 1)
53 <F3> send: apply:withArgs:
54 <90> jumpTo: 56
55 <73> pushConstant: nil
56 <7C> returnTop

-- Yoshiki

I can't reproduce this.  When I debug the following doit (which mimics your code) and inspect the context  I get a valid decompilation:

| t |
       ^ true
               ifTrue: [t := self apply: #anything.
                       self apply: #spaces.
                       self apply: #seq withArgs: {t}]

the same code:

method symbolic
'37 <71> pushConstant: true
38 <AC 0F> jumpFalse: 55
40 <70> self
41 <21> pushConstant: #anything
42 <E0> send: apply:
43 <68> popIntoTemp: 0
44 <70> self
45 <22> pushConstant: #spaces
46 <E0> send: apply:
47 <87> pop
48 <70> self
49 <24> pushConstant: #seq
50 <10> pushTemp: 0
51 <8A 81> pop 1 into (Array new: 1)
53 <F3> send: apply:withArgs:
54 <90> jumpTo: 56
55 <73> pushConstant: nil
56 <7C> returnTop
'

and decompileWithTemps returns something correct:

method decompileWithTemps
DoIt
| t |
^ true
ifTrue: [t := self apply: #anything.
self apply: #spaces.
self apply: #seq withArgs: {t}] 

So has OMeta patched some old bug in the decompiler which is now obsoleted by some other fix?

The difference appears to be that the OMeta compiler answers '(t)[(t)[(t)]]' for the schematicTempNamesString. The regular compiler answers 't'. This trips the Decompiler over.

Bingo.  OMeta looks to be computing the schematic temps for the method before inlining and closure analysis, in that the ifTrue: argument is an actual block according to that string.  Good catch!
 

- Bert -








--
best,
Eliot



Reply | Threaded
Open this post in threaded view
|

Re: Decompilation problem

Yoshiki Ohshima-3
At Thu, 12 Apr 2012 18:08:01 -0700,
Eliot Miranda wrote:
>
>         So has OMeta patched some old bug in the decompiler which is now obsoleted by some other fix?
>
>     The difference appears to be that the OMeta compiler answers '(t)[(t)[(t)]]' for the schematicTempNamesString. The regular compiler answers 't'. This trips the Decompiler over.
>
> Bingo.  OMeta looks to be computing the schematic temps for the method before inlining and closure analysis, in that the ifTrue: argument is an actual block according to that string.  Good
> catch!

I understand what you mean, but I still cannot see how this can
happen.  What I do is to load OMeta2 from
http://www.squeaksource.com/OMeta.html, go to a method like
OMeta2Examples>>fact in the broser and and press the "decomple"
button.  (The actual schematicTempNamesString is different and you get
different symptom, but it seems to be stemming from the same problem.)

In the current implementation it comes down to something like:

(Parser new parse:  'fact
        | m n |
        ^ self ometaOr: {[true
                        ifTrue: [true
                                        ifTrue: [self apply: #exactly withArgs: {0}].
                                self ometaOr: {[true
                                                ifTrue: [1]]}]]. [true
                        ifTrue: [true
                                        ifTrue: [n := self apply: #anything].
                                self ometaOr: {[true
                                                ifTrue: [m := self apply: #fact withArgs: {n - 1}.
                                                        n * m]]}]]}' readStream class: Object noPattern: false context: nil notifying: nil ifFail: []) generate: CompiledMethodTrailer defaultMethodTrailer;
                                                                                schematicTempNamesString.

and I get "'(m n)[[]][(m n)[(m n)]]'" as its results.  Is there a call
to make other than parse:class:noPattern:context:notifying:ifFail:?

-- Yoshiki