Feature #18660: Line event flags on instruction in method/block signature

• Status: Closed
• Assignee: -
• Target version: -

[hurricup (Alexandr Evstigneev)]

Ruby in question is 3.0.3. Not sure what behavior is on different versions, but presume the same.

It's unclear why operations in signatures are not marked with Li, despite they may be a valid and meaningful code. Consider example:

class A
  def foo(some = BasicObject.new)
    yield
  end
end

A.new.foo {|a = BasicObject.new| 1 + a}

And here is the disasm of method iseq:

local table (size: 1, argc: 0 [opts: 1, rest: -1, post: 0, block: -1, kw: -1@-1, kwrest: -1])
[ 1] some@0<Opt=0>
0000 opt_getinlinecache                     9, <is:0>                 (   2)
0003 putobject                              true
0005 getconstant                            :BasicObject
0007 opt_setinlinecache                     <is:0>
0009 opt_send_without_block                 <calldata!mid:new, argc:0, ARGS_SIMPLE>
0011 setlocal_WC_0                          some@0
0013 invokeblock                            <calldata!argc:0, ARGS_SIMPLE>(   3)[LiCa]
0015 leave                                                            (   4)[Re]

Here is the block iseq:

local table (size: 1, argc: 0 [opts: 1, rest: -1, post: 0, block: -1, kw: -1@-1, kwrest: -1])
[ 1] a@0<Opt=0>
0000 opt_getinlinecache                     9, <is:0>                 (   7)
0003 putobject                              true
0005 getconstant                            :BasicObject
0007 opt_setinlinecache                     <is:0>
0009 opt_send_without_block                 <calldata!mid:new, argc:0, ARGS_SIMPLE>
0011 setlocal_WC_0                          a@0
0013 nop                                    [Bc]
0014 putobject_INT2FIX_1_                   [Li]
0015 getlocal_WC_0                          a@0
0017 opt_plus                               <calldata!mid:+, argc:1, ARGS_SIMPLE>
0019 nop
0020 leave                                                            (   7)[Br]

And this is a bit confusing.

1. I would expect Ca/Bc events to be fired on the first instruction, not in the middle of iseq
2. I would expect Li to exist on pc=0 for the both method and block

[mame (Yusuke Endoh)]

I think it is by design. Call events are fired after evaluation of optinal arguments. Line events are not fired during evaluation of optional arguments.

I would expect Ca/Bc events to be fired on the first instruction, not in the middle of iseq
I would expect Li to exist on pc=0 for the both method and block

Can you elaborate why you expect so? Do you have any actual problem or use case?

[ko1 (Koichi Sasada)]

• Status changed from Open to Closed

I understand the request, but current specification is because of the current implementation (I don't have good idea to implement it without performance penalty).
I have several ideas to do it (without performance penalty) but it needs big change, so I hesitate about it.
(one idea is multi-head iseq)

[hurricup (Alexandr Evstigneev)]

ko1 (Koichi Sasada) wrote in #note-2:

I understand the request, but current specification is because of the current implementation (I don't have good idea to implement it without performance penalty).

I see. Are you saying that Li flags causing performance degradation even if there are no trace points set?

[hurricup (Alexandr Evstigneev)]

ko1 (Koichi Sasada) wrote in #note-2:

I understand the request, but current specification is because of the current implementation (I don't have good idea to implement it without performance penalty).

And one more question. If I want my debugger to be able to stop on the signature code, would it be enough to find insn_infos for the signature instructions and set RUBY_EVENT_LINE for them? Or do I need to do something else?

[Eregon (Benoit Daloze)]

@ko1 (Koichi Sasada) What's the performance problem to have the line event on the first bytecode?
Why is it more expensive to check it on the first bytecode than on the bytecode a bit later?