I have nothing to add to the accurate answers Yury provided, but Yury can you provide some details on the security related problems you are working on solving?
/Søren On Wed, Jan 6, 2010 at 10:37, Yury Semikhatsky <[email protected]> wrote: > 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
