diff options
author | Björn Gustavsson <[email protected]> | 2011-09-29 15:05:20 +0200 |
---|---|---|
committer | Björn Gustavsson <[email protected]> | 2011-11-07 14:00:26 +0100 |
commit | a772f06a2de3b83e8b21072eeae837e05f7b46e7 (patch) | |
tree | 65723e3695d7d1e35e2602e2d6f5ed52ca5c6210 /lib/compiler/src/beam_utils.erl | |
parent | af5edfe20b24116fa892a37a746f4053fde6039b (diff) | |
download | otp-a772f06a2de3b83e8b21072eeae837e05f7b46e7.tar.gz otp-a772f06a2de3b83e8b21072eeae837e05f7b46e7.tar.bz2 otp-a772f06a2de3b83e8b21072eeae837e05f7b46e7.zip |
beam_asm: Fix broken NewIndex in fun entries
The calculation of the NewIndex field in fun entries is broken: the
sys_pre_expand and v3_kernel modules keep separate index counters
starting at zero; thus there is no guarantee that each fun within a
module will have its own unique NewIndex.
We don't really need the NewIndex any more (see below), but since
we do need the NewUniq field, we should fix NewIndex for cleanliness
sake. The simplest way is to assign NewIndex as late as possible,
namely in beam_asm, and to set it to the same value as Index.
Historical Note: Why NewIndex Was Introduced
There was once an idea that the debugger should be able to interpret
only a single function in a module (for speed). To make sure that
interpreted funs could be called from BEAM code and vice versa,
the fun identification must be visible in the abstract code.
Therefore a NewIndex field was introduced in each fun in the abstract
code.
However, it turned out that interpreting single functions does not
play well with aggressive code optimization. For example, in this
code:
f() ->
X = 1,
fun() -> X+2 end.
the variable X will seem to be free in the fun, but an aggressive
optimizer will replace X with 1 in the fun; thus the fun will no
longer have any free variables. Therefore, the debugger will always
interpret entire modules.
Diffstat (limited to 'lib/compiler/src/beam_utils.erl')
0 files changed, 0 insertions, 0 deletions