diff options
author | Björn Gustavsson <[email protected]> | 2017-09-30 07:48:34 +0200 |
---|---|---|
committer | Björn Gustavsson <[email protected]> | 2017-09-30 09:43:33 +0200 |
commit | 9a50a5d5fc1c74d91efad74e1cb3e78f38e2b75c (patch) | |
tree | 5999ee43220e0c7823f4651b1f3b5731825804b3 /erts/emulator/beam/macros.tab | |
parent | d0875a87fc59bea515294455b2047040118f3a7e (diff) | |
download | otp-9a50a5d5fc1c74d91efad74e1cb3e78f38e2b75c.tar.gz otp-9a50a5d5fc1c74d91efad74e1cb3e78f38e2b75c.tar.bz2 otp-9a50a5d5fc1c74d91efad74e1cb3e78f38e2b75c.zip |
Point out the correct line number in stack traces
Sometimes the line number in a stack trace could be wrong,
for example for this code:
t() ->
Res = id(x), %<== Wrong line number.
Res + 1.
id(I) -> I.
The line number pointed out in the stack trace would be the
line before the line where the exception occurred.
The reason is the way the increment instruction instruction
is implemented:
OpCase(i_increment_rWtd):
{
increment_reg_val = r(0);
}
I -= 1;
goto increment__execute;
OpCase(i_increment_xWtd):
{
increment_reg_val = xb(I[1]);
}
goto increment__execute;
increment__execute:
/* Common code for increment */
.
.
.
(The implementation in OTP 20 is similar, but hand-coded directly
in beam_emu.c instead of generated.)
The instruction i_increment_rWtd decrements the instruction pointer (I)
before jumping to the common code. That means that I points *before*
the 'increment' instruction. If there is a 'line' instruction directly
before the 'increment' instruction (as there is in this example), the
instruction pointer will point before that line. Thus the previous line
will be picked up instead.
To eliminate this bug, we must never decrement the instruction pointer.
Instead, we can increment the other (longer) instructions in the
same group of combined instructions:
OpCase(i_increment_rWtd):
{
increment_reg_val = r(0);
}
goto increment__execute;
OpCase(i_increment_xWtd):
{
increment_reg_val = xb(I[1]);
}
I += 1;
goto increment__execute;
increment__execute:
/* Common code for increment */
.
.
.
Also fix a bug that was only a potential bug when ddaed7774eb0a
introduced relative jumps, but is now a real bug. See the added
comment for SET_I_REL() in macros.tab.
Diffstat (limited to 'erts/emulator/beam/macros.tab')
-rw-r--r-- | erts/emulator/beam/macros.tab | 11 |
1 files changed, 10 insertions, 1 deletions
diff --git a/erts/emulator/beam/macros.tab b/erts/emulator/beam/macros.tab index 6f9b78af6f..0d175a7ec6 100644 --- a/erts/emulator/beam/macros.tab +++ b/erts/emulator/beam/macros.tab @@ -28,9 +28,18 @@ REFRESH_GEN_DEST() { dst_ptr = REG_TARGET_PTR(dst); } +// $Offset is relative to the start of the instruction (not to the +// location of the failure label reference). Since combined +// instructions may increment the instruction pointer (e.g. in +// 'increment') for some of the instructions in the group, we actually +// use a virtual start position common to all instructions in the +// group. To calculate the correct virtual position, we will need to +// add $IP_ADJUSTMENT to the offset. ($IP_ADJUSTMENT will usually be +// zero, except in a few bit syntax instructions.) + SET_I_REL(Offset) { ASSERT(VALID_INSTR(*(I + ($Offset)))); - I += $Offset; + I += $Offset + $IP_ADJUSTMENT; } SET_CP_I_ABS(Target) { |