Debugger with inlined methods

On Tue, Oct 11, 2016 at 9:45 PM, Esteban Lorenzano <[hidden email]> wrote:
>
>> On 11 Oct 2016, at 15:43, Vitor Medina Cruz <[hidden email]> wrote:
>>
>> Hello,
>>
>> I was TTDing today with Pharo and some odd thing happened. I had a method that just returned false and while debugging I could not step into it (i wanted to change the method while debugging), I suppose the method was inlined and so debugging was not available, is that correct?
>
> yes.

The same also happens for accessors that return an instance variable
directly.  I often find It unsettling, to be expecting one behaviour
and something different occurs, even if a moment later I implicitly
understand what happened.

Except of course that someone busy would have to do it, how hard would
it be for the debugger to un-inline the method so it can step into it?
 Are there any reasons not to do that?

cheers -ben

Well for quick methods it's doable.

For inlined control flow operations it's quite difficult. Although it could be possible now with the mustBeBoolean magic thingy...

On Thu, Oct 13, 2016 at 3:23 PM, Vitor Medina Cruz <[hidden email]> wrote:

Ben,

I was thinking the same as you, I think that if I could set the image in development mode, or something like that, it would not do such optimization so that debugger behaves more like expected. If the debugger could undo such optimizations would be fine also. I just assumed it should be hard to accomplish that.....

Regards,

Vitor

On Wed, Oct 12, 2016 at 9:38 AM, Clément Bera <[hidden email]> wrote:

The simulation of primitives is done in Context>>#doPrimitive:method:receiver:args: 

Basically, specific numbers are simulated in the image while other numbers are run using the VM code.

Quick methods (what you call inlined methods) are encoded with primitive numbers between 256 and 512. If you look at IRBytecodeGenerator>>quickMethodPrim you should be able to find the specification of the quick primitive numbers (256 = quick return self, 257 = quick return true, etc...). 

Basically if you change this method to simulate in the image those primitive numbers instead of using the VM code and simulating by creating the context and executing it, it should work. Or something like that.

On Wed, Oct 12, 2016 at 2:18 PM, Ben Coman <[hidden email]> wrote:

On Tue, Oct 11, 2016 at 9:45 PM, Esteban Lorenzano <[hidden email]> wrote:
>
>> On 11 Oct 2016, at 15:43, Vitor Medina Cruz <[hidden email]> wrote:
>>
>> Hello,
>>
>> I was TTDing today with Pharo and some odd thing happened. I had a method that just returned false and while debugging I could not step into it (i wanted to change the method while debugging), I suppose the method was inlined and so debugging was not available, is that correct?
>
> yes.

The same also happens for accessors that return an instance variable
directly.  I often find It unsettling, to be expecting one behaviour
and something different occurs, even if a moment later I implicitly
understand what happened.

Except of course that someone busy would have to do it, how hard would
it be for the debugger to un-inline the method so it can step into it?
 Are there any reasons not to do that?

cheers -ben