On Thu, Jan 21, 2010 at 21:03, Peter Rybin <[email protected]> wrote:
> Hi Søren > > The setbreakpoint request supports setting a breakpoint on a function (type >> = 'function'), and that requires an evaluation. It is currently a global >> evaluation, but that might actually not be what users expect. Perhaps >> setpreakpoint of type function should require a suspended VM, and no longer >> use global evaluate as well. >> > > We may want to make a compromise about this. Do I understand right that > type = 'function' only makes sense for command-line-based debuggers? I can't > see how standard UI debugger may make use of such breakpoint parameter. > I think it is only natural for UI debugger to be able to set breakpoints > asynchronously, i.e. beyond suspended state. Maybe we should keep this > capability for line-number-based breakpoints and look at type = 'function' > as at a separate case. > > I think the 'function' type break point makes sense for all type of debuggers, but it might be that it should only be allowed by something like the Eclipse debugger when we are suspended. When on a break point you might have a function object somewhere (e.g. in some argument somewhere on the stack) that you will like to break in.* *It might be that you can figure out the script and use that for setting a break point. In the Chrome DevTools we have the console and perhaps it should be possible to set a break in a function from there. > Regarding the refs (mirror objects) then is is correct that these are only >> valid within the same break. However we should start thinking about making >> it possible to have then survive several breaks. You might want to have a >> watch on an object which is only available through a handle. Also if the >> debugger shows the object handle id then in a debugging session ti would be >> easy the see whether it is the same object which shows up from break to >> break. I remember Alexander mentioning that Eclipse has something like that >> for its Java debugging. >> > > Okay. I see it may make a new feature or two to develop. > I can say that Eclipse plugin already shows refs for JavaScript objects. Of > course they only make sense in scope of one suspend period. Nevertheless it > still may be useful to tell whether 2 objects are the same. > > The watch expression that just catches some pointer is definitely a feature > I have long wanted in almost any IDE I worked with, but it's a bit > surprising that I have never seen such feature. I do not know why. > > This should probably include some kind of "scoping" debugger command to >> indicate handles should be persistent from a certain point as otherwise we >> could end up with a mirror of all objects in the heap. This will require the >> handle cache to be moved from JavaScript in the debugger context into C++ >> code where they should be kept through weak handles. >> > > When making refs permanent we may also want to implement "reset" command > that resumes and immediately suspends in the same point but clears mirrors > map. May be useful, when id's became too large (with many digits) and thus > inconvenient. > Yes, and we might have to add some cap in the internal cache as well and flush (some of) it if it uses to much memory. > > Peter > > > >> >> /Søren >> >> On Mon, Jan 18, 2010 at 13:42, Peter Rybin <[email protected]> wrote: >> >>> 2010/1/18 Søren Gjesse <[email protected]> >>> >>> Hi Peter >>>> >>>> What you are suggesting is that when there is no active JavaScript >>>> execution and the embedder calls v8::Debug::ProcessDebugMessages() the >>>> embedder can enter a context before the call, and the commands will be >>>> processed in this context. I think that sounds fine. However I am not sure >>>> whether the call to suspend is actually required for this to work. Should >>>> that be required for commands like "setbreakpoint" which can also include >>>> evaluating an expression? In my initial design I >>>> >>> >>> Maybe I said it too restrictive. >>> Anyway, I don't think "setbreakpoint" command or similar requires >>> suspend. I would call them "asynchronous" commands, because they may be >>> handled equally successfully in any moment. >>> >>> As for evaluate, I am not going to restrict anything, at least for >>> now. However, I would suggest that "evaluate" normally should be issued when >>> debugger is in suspend state; I see 2 reasons here: >>> 1. As I understand, "refs" are only while we are staying on suspend. This >>> probably means that lookup subproperties we should be suspended. >>> 2. Debugger UI frameworks may expect that expressions are only evaluated >>> in suspend state and be reluctant to evaluate them in other states. >>> >>> What I actually wanted to say, that I am going to have "suspend" command >>> properly handled even when V8 is not active. When user sends us "suspend", >>> embedder calls the usual "ProcessDebugMessages", which blocks on suspend >>> until user sends "continue". This way we deal nicely with both issues above. >>> >>> I don't expect myself to say something really original or new here. I >>> just wanted to give a small specification just in case. >>> >>> Peter >>> >>> >>> >>> >>>> mandated that V8 was suspended before any commands could be processed, >>>> but was convinced it change it and add the "auto break" processing. It will >>>> of cause be fine that a debugger restricts its use of the protocol to >>>> something that makes sense for how it work. >>>> >>>> /Søren >>>> >>>> On Fri, Jan 15, 2010 at 21:43, Peter Rybin <[email protected]>wrote: >>>> >>>>> Hi Søren >>>>> >>>>> Let me share the idea of "global evaluate" implementation. >>>>> >>>>> Use case 1: >>>>> Some web application is open in Chrome browser. Programmer wishes to >>>>> inspect a value of some global variable without any JavaScript code >>>>> actually >>>>> running (e.g. his web-page has only one function, and this function will >>>>> trigger drawbridge opening over the river Neva). >>>>> Debugger should allow checking a global variable. >>>>> >>>>> Use case 2: >>>>> Some application occasionally employs some user scripting. Programmer >>>>> wishes to call GetEmbedderConfiguration() function and inspect an object >>>>> it >>>>> returns with its properties and subproperties. Making application run >>>>> actual >>>>> user script is a long non-automated routine, that has to be done manually. >>>>> Debugger should allow calling any global function. >>>>> >>>>> Use case 3 (optional): >>>>> Some application support several V8 contexts. While application is >>>>> idle, programmer wishes to check initial data in all contexts. >>>>> When application is idle, debugger should give access to all contexts >>>>> (because we cannot explicitly choose a particular one). >>>>> >>>>> >>>>> Here's my approach. >>>>> When application is idle (or simply V8 is not called) programmer >>>>> presses "suspend" button. "Suspend" debug command arrives to V8 and >>>>> embedder >>>>> calls v8::Debug::ProcessDebugMessages(). V8 suspends and send back >>>>> "suspended" event. In this situation V8 is suspended, but there are no >>>>> frames. Everybody is cool about this. Debugger application (e.g. Eclipse) >>>>> sees that we are suspended and evaluates required expressions. V8 is can >>>>> correctly evaluate expressions, because it is suspended and therefore all >>>>> data is static and may be inspected. >>>>> >>>>> I have tried to implement this, it seems to require quite a few simple >>>>> modifications. >>>>> >>>>> Embedder is responsible for choosing a context to >>>>> call v8::Debug::ProcessDebugMessages(). For use case #3 I would suggest >>>>> that >>>>> embedder creates an auxiliary context, that keeps references to all user >>>>> contexts. This way programmer will be able to inspect all contexts in this >>>>> manner: >>>>> expression1 = "this.rybin_context.GetConfiguration()" >>>>> expression2 = "this.apavlov_context.window" >>>>> >>>>> I'm going to complete/submit this in a near future. >>>>> Do you think this may sound reasonable? >>>>> >>>>> Peter >>>>> >>>> >>>> >>> >> > -- v8-dev mailing list [email protected] http://groups.google.com/group/v8-dev
