[bug] Line numbers not reported at start of blocks

Issue status update for
http://smalltalk.gnu.org/node/858
Post a follow up:
http://smalltalk.gnu.org/project/comments/add/858

 Project:      GNU Smalltalk
 Version:      <none>
 Component:    VM
 Category:     bug reports
 Priority:     normal
 Assigned to:  Unassigned
 Reported by:  bush
 Updated by:   bush
 Status:       active

At the start of a block, a line number bytecode is not generated.  This
is compounded when blocks contain only statements that are messages to
blocks or when blocks are stored for later evaluation.

The following code will highlight this:
[ [
   Processor activeProcess context backtrace
 ] value.
 [
   Processor activeProcess context backtrace
 ] value
] value

Evaluation will produce:
optimized [] in UndefinedObject>>executeStatements (LineNumberTest.st:3)
optimized [] in UndefinedObject>>executeStatements (LineNumberTest.st:1)
UndefinedObject>>executeStatements (LineNumberTest.st:1)
optimized [] in UndefinedObject>>executeStatements (LineNumberTest.st:6)
optimized [] in UndefinedObject>>executeStatements (LineNumberTest.st:1)
UndefinedObject>>executeStatements (LineNumberTest.st:1)

The second and fifth output lines are showing the start of the outer
block, but should be showing the start of the inner blocks.

The code to request a line number bytecode is in libgst/comp.c (line
1227) using flag LN_FORCE, but in libgst/byte.c this does not generate a
line number bytecode.  The enclosed patch will allow a line number
bytecode to be produced in this situation (this is the only place where
LN_FORCE is used).  With this, the output from the above code becomes:
optimized [] in UndefinedObject>>executeStatements (LineNumberTest.st:3)
optimized [] in UndefinedObject>>executeStatements (LineNumberTest.st:2)
UndefinedObject>>executeStatements (LineNumberTest.st:1)
optimized [] in UndefinedObject>>executeStatements (LineNumberTest.st:6)
optimized [] in UndefinedObject>>executeStatements (LineNumberTest.st:5)
UndefinedObject>>executeStatements (LineNumberTest.st:1)

Here, the correct lines for the inner blocks are displayed.



_______________________________________________
help-smalltalk mailing list
[hidden email]
https://lists.gnu.org/mailman/listinfo/help-smalltalk

On 10 May 2014, at 17:25, Mark Bush <[hidden email]> wrote:
> At the start of a block, a line number bytecode is not generated.  This
> is compounded when blocks contain only statements that are messages to
> blocks or when blocks are stored for later evaluation.

I just noticed that the patch I provided seems not to have made it, so here it is...

--- a/libgst/byte.c
+++ b/libgst/byte.c
@@ -151,6 +151,8 @@ _gst_line_number (int n, int flags)
            {
              _gst_compiler_state->prev_line = n;
              next_line_number = n - _gst_compiler_state->line_offset;
+             if (!_gst_omit_line_numbers)
+               compile_byte (LINE_NUMBER_BYTECODE, next_line_number);
            }
        }
     }


_______________________________________________
help-smalltalk mailing list
[hidden email]
https://lists.gnu.org/mailman/listinfo/help-smalltalk

On Sat, May 31, 2014 at 10:22:27PM +0100, Mark Bush wrote:

Dear Mark,

> I just noticed that the patch I provided seems not to have made it, so here it is...

thank you for your contribution. There are three issues related to that
patch. The first is that after applying this change the "make check"
command has two regressions. One is in xlat.st and the other in the
DebugTools.st. The other is that we have played ping-pong with line
number changes/fixes so we will need to add a testcase to avoid
further ping-pong.

In more details:

* xlat.st: The code includes the dump of the bytecode. Now that line
  numbers change the output of the test needs to be updated. While
  looking at the output I see things like these:

+   [21]        push 0
+   [23]        source code line number 31
+   [25]        source code line number 31

 These instructions will be dispatched at runtime. This means your
 code has the potential the number of bytecodes we need to execute
 during execution. It will most likely be a performance hit. So the
 question is how to fix the line number issue you have without
 doubling the number of bytecodes per method.

 s := 0. CompiledCode allSubinstancesDo: [:each | s := s + each size ]. s
 152300 vs. 117946. The extra bytecodes add around 33.43 kb on the
 standard image

* DebugTools.st: The  DebuggerTest>>#testRegressionCurrentLine test
  fails. I think it is because bytecode like

    [3] source code line number 3
    [5] source code line number 3

* Tests: We have a mix of testcode that simply captures the output
  of the execution and some SUnit based tests. For kernel code we
  started to use packages/kernel-tests/ to add SUnit based tests.
  It is probably the place where you would like to add your regression
  test for the compiled methods.


In conclusion from my point of view. Please add a test case, please
minimize the bytecode overhead for line numbers, please update the
tests that now need to be updated.

kind regards
        holger

_______________________________________________
help-smalltalk mailing list
[hidden email]
https://lists.gnu.org/mailman/listinfo/help-smalltalk