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 <b...@openinworld.com> wrote: > On Tue, Oct 11, 2016 at 9:45 PM, Esteban Lorenzano <esteba...@gmail.com> > wrote: > > > >> On 11 Oct 2016, at 15:43, Vitor Medina Cruz <vitormc...@gmail.com> > 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 > >
