- Replaced the way code structures are identified by the parser.
Previously, the scanner introduced some COME_FROM entries in the
dissasembly output to mark all the destinations of jump instructions.
Using these COME_FROM labels the parser was then able to identify the
code structures (if tests, while loops, etc). Up to python-2.3 this was
possible because the code structures were clearly defined and jump
targets were always to the same points in a given strcuture making it
easy to identify the structure. Python 2.3 however introduced optimized
jumps to increase code performance. In the previous version of decompyle
(2.3) we used a technique to identify the code structures and then used
these structures to determine where the jump targets would have been if
not optimized. Using this information we then added COME_FROM labels at
the points where they would have been if not optimized, thus emulating
the way decompyle worked with versions before python 2.3. However with
the introduction of even more optimizations in python 2.4 this technique
no longer works. Not only the jump targets are no longer an effective
mean for the parser to identify the code structures, but also trying to
emulate the old way things were solved when it clearly no longer works
is not the right solution. To solve this issue, the code to identify the
structures that we had developed in version 2.3, was used to add real
start/end points for strcuture identification, instead of the COME_FROM
labels. Now these new start/end labels are used by the parser to more
precisely identify the structures and the COME_FROM labels were removed
completely. The scanner is responsible to identify these code structures
and use any knowledge of optimizations that python applies to determine
the start/end points of any structure and then mark them with certain
keywords that are understood by the parser.
- Correctly identify certain `while 1' structures that were not
recognized in the previous version.
- Added support for new byte code constructs used by python 2.4