Thanks eliot. I really think that pushing the debugger to the next level is an exciting perspective and I'm super happy that thomas accepted my crazy topics.
Stef On Fri, Jun 2, 2017 at 2:08 AM, Eliot Miranda <[email protected]> wrote: > Hi Guille, > > On Wed, May 31, 2017 at 12:48 AM, Guillermo Polito < > [email protected]> wrote: > >> >> >> On Mon, May 29, 2017 at 6:07 PM, Eliot Miranda <[email protected]> >> wrote: >> >>> Hi Thomas, >>> >>> >>> On May 29, 2017, at 7:41 AM, Ben Coman <[email protected]> wrote: >>> >>> >>> >>> On Mon, May 29, 2017 at 9:34 PM, <[email protected]> wrote: >>> >>> [...] >> >>> >>>> Here is my example code. Beware, running it will freeze the VM. >>>> >>>> | program process context debugSession | >>>> program := [1+2]. >>>> process := program newProcess. >>>> context := process suspendedContext. >>>> debugSession := process newDebugSessionNamed: 'StepIntoForever' >>>> startedAt: context. >>>> [ true ] whileTrue: [ debugSession stepInto ]. >>>> >>>> [...] >> >> >>> In particular, your use of stepInto: will soon step into the process >>> termination code. See newProcess. You have to stop simulating before you >>> stop the current process by mistake. >>> >>> >> Yes, I explained yesterday to Thomas that this would end up terminating >> the UIProcess where the debugger is running on, instead of terminating the >> process that is being debugged. But, it looks like a bug... >> >> It would make sense to me that "Processor activeContext" yields the >> debugged context in the simulated code instead of the real active context. >> And I believe that this change should not break any existing code. >> >> Actually, thinking a bit more about this, similar problems may happen if >> we try to execute in the debugger Semaphore code in the debugger. So >> probably, in general terms, the debugger should handle specially all code >> that messes up with the Process machinery. >> > > Alas is isn't possible to implement this directly in the execution > simulation machinery because of things like this: > > Context>>runUntilErrorOrReturnFrom: > Context>>jump > > Context>>jump uses the simulation machinery to advance execution, so the > execution simulation machinery has to simulate exactly. > Context>>runUntilErrorOrReturnFrom: > uses Context>>jump and is used in the exception delivery process. > > I expect the process state changing primitives can apply to > effectiveProcess. So in Context>>doPrimitive:method:receiver:args:see > > "Mutex>>primitiveEnterCriticalSection > Mutex>>primitiveTestAndSetOwnershipOfCriticalSection" > (primitiveIndex = 186 or: [primitiveIndex = 187]) ifTrue: > [| effective | > effective := Processor activeProcess effectiveProcess. > "active == effective" > value := primitiveIndex = 186 > ifTrue: [receiver primitiveEnterCriticalSectionOnBehalfOf: effective] > ifFalse: [receiver primitiveTestAndSetOwnershipOfCriticalSectionOnBehalfOf: > effective]. > ^(self isPrimFailToken: value) > ifTrue: [value] > ifFalse: [self push: value]]. > > > We would have to have similar code for suspend and resume primitives. I > don't see how this mechanism solves the issues with wait and signal > though. They need to be handleable as per > primitiveEnterCriticalSectionOnBehalfOf: > etc. We would have to modify the VM and add signalOnBehalfOf: and > waitOnBehalfOf:. There might be a bug tail here because I fear that the > system depends on these being 0 argument primitives to avoid stack growth > on signal/wait. > > -- >> >> >> >> Guille Polito >> >> >> Research Engineer >> >> French National Center for Scientific Research - *http://www.cnrs.fr* >> <http://www.cnrs.fr> >> >> >> >> *Web:* *http://guillep.github.io* <http://guillep.github.io> >> >> *Phone: *+33 06 52 70 66 13 <+33%206%2052%2070%2066%2013> >> > > > > -- > _,,,^..^,,,_ > best, Eliot >
