Resending this question to the public mailing list. It may be of interest for someone else.
> [-v8-team, [email protected]] > Hi Peter, > On Tue, Jan 5, 2010 at 8:37 PM, Peter Rybin <[email protected]> wrote: > Hi Soren > >> > Working on v8 application debugging sample I finally ran into a question > about contexts. > >> > How do we support multiple contexts in V8 debug model? > There is no notion of context in the debugger protocol. When on a breakpoint you can specify a scope where to evaluate an expression and v8 will enter corresponding context before performing the evaluation(the entered context is basically used for new objects construction and for security checks). If the JS code you debugging already has access to an object created in another context you can inspect it just the same way as the objects from the current context. If a function on the current call stack don't have access to the object from another context then you can only access it by means of the embedding application. E.g. the debugger may invoke a callback when it is on the breakpoint and the embedder can enter the context of interest and trigger the debugger again. Most of the time it would bring the same result as if the execution was resumed and then evaluation was performed. We might want to support evaluation in a specified context in V8 debugger protocol at some point but there has not been a need for that functionality so far. Do you have a real use case for that? > Do we support multiple contexts at all? > V8 doesn't keep explicit references to created contexts. It is the embedder who is supposed to enter right context and specify global object('this' object in terms of JavaScript) when calling a JS function. As I said there is no such notion as context in the debugger protocol. Speaking about implementation there is an only debugger context which is used for debugger operations no matter objects from which context you are debugging. I'm thinking about changing this for some security considerations but I don't think this implementation detail should be exposed through the protocol. > > Should we imply that user has to choose a single context that is > debuggable? Or even request him to choose it explicitly and let us know. > I don't quite understand your question. A breakpoint cannot be set on a context and a function from one context can be invoked in a scope of another context. The current context can be derived from the current call stack and since we always have one there is no need to burden the user with context specification. > > > Should V8 debug protocol connection be scoped to a particular context or > should data from all contexts' data be available to debugger via single > connection? > The idea is to expose all the data via the debugger protocol no matter which context it comes from. > > If embedding application calls "void(0)" to let V8 process pending > commands, in which context this empty script should be run (when there are > several contexts)? > It is up to the embedder how it evaluates the code. Among other things it should enter a context where the code will be compiled. If you have no other options you can always evaluate the code in the debugger context. > > > Can evaluate command process expressions from various contexts? > >> E.g. V8 is paused in one context, but "evaluate" command specifies other > context as target. > > The expression is a string and it is evaluated in a particular scope(which is specified as the command argument) if the code in that scope does have access to the objects from other contexts they can be used in the expression too. You cannot specify a context for 'evaluate' command explicitly(moreover there are no means in the protocol for addressing the contexts) instead it will be derived from the call frame that was specified. > > Could you please clarify it for me? Or maybe we ought to discuss it. > >> > > Yury, I might miss how you did it in Chrome. > I'm currently working on support for several contexts in the dev tools but it's all about security. I'm going to change the debugger implementation a bit for the same reason(we need to somehow isolate objects with different origins from each other) but I didn't plan to expose that through the protocol. > > > Thank you, > Peter > > > Thanks, Yury
-- v8-dev mailing list [email protected] http://groups.google.com/group/v8-dev
