The object delivered to the debug message handler contains additional information on the current break handling the messages.
Clients which require just JSON message parsing can simply get the JSON using the GetJSON message on the message object to still have the previous behaviour.
NewMessageHangler(const v8::Debug::Message& message) {
v8::String::Value val(message.GetJSON());
OldMessageHandler(Vector<uint16_t>(const_cast<uint16_t*>(*val), val.length()));
}
Refactored some of the debugger code to use internal handles instead of API handles. Also changed Object to JSObject is some places.
The access to the active context when the break occurred is still not implemented. I will add this in a new CL, as this one is quite big already.
Review URL: http://codereview.chromium.org/99122
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@1811 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
The debug message thread was introduced to make it possible to have the message handler callback be called from a different thread than the thread running V8 where the debug event occoured, but it never had any practical use, and prevents providing information to the message handler which is only available from the V8 thread.
In the future any thread decoupling will have do be done by the embedder.
This also removes the queue used for outbound messages.
Renamed the class Message to CommandMessage as it is only used for debugger commands from the client. Related message queue classes has also been renamed.
Review URL: http://codereview.chromium.org/93118
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@1788 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
For keyed IC loads setting a break point now ensures that the inlined code is not used. When the break point is set the inlined map check is changed to fail causing the inlined code not to be used but the IC to be called. As long at the break point is set the map check will stay invalid.
Review URL: http://codereview.chromium.org/87025
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@1756 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
The generic step-in mechanism floods the function called with break points to ensure a break is hit when entering the function. This generic mechanism was also used for function.apply. The code for function.apply contains a keyed load IC which was patched when stepping into function.apply. However function.apply enteres an internal frame not a JavaScript frame. This caused the logic for returning from the break in function.apply to fail as it forced a jump to the IC on the top JavaScript frame. The top JavaScript frame was the frame for the function calling function.apply not the frame for the apply function. Now returning from the break point in the keyed load IC in the apply code caused a jump to the code for the call IC for the function calling function.apply in the first place. Not a pretty sight.
Step-in now handles function.apply as a separate case where the actual JavaScript function called through apply is flodded with breakpoints instead of the function.apply function.
BUG=269
BUG=8210@chromium.org
Review URL: http://codereview.chromium.org/63055
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@1683 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
Add a semaphore for accessing debugger varaibles which can be changed from a different thread. This is mainly the debug message handler which can be set to NULL to disconnect the debugger.
Control the unloading of the debugger from the V8 thread. Before the debugger unload was called from the thread setting the debug message handler to NULL. This was not safe as this involves calling into V8. This change handles the unloading of the debugger either when entering a debugger event and the debugger was disconnected while the debugger was not active or when leaving the debugger and the debugger was disconnected while the debugger was active.
Add a flag to avoid unloading the debugger if debugger code is used by the application for other purposes than debugging.
Added tests for clearing the debug message handler.
Review URL: http://codereview.chromium.org/56102
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@1648 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
When the debugger agent terminates the used port can be stuck in TIME_WAIT for some time depending on the OS and the state of the socket. With this change will allow the debug agent to start listening on a port still in TIME_WAIT. During development of both V8 and embedding applications this makes it much easier to restart an application using the debugger agent.
This also makes it possible to run the tests involving the debugger agent multiple times without failure.
Review URL: http://codereview.chromium.org/50050
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@1558 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
During bind and listen socket errors are now handled. If the listen socket is occoupied the agent will retry its bind operation until success or shutdown.
Added orderly shutdown of the debugger agent both with and without a client connected.
Review URL: http://codereview.chromium.org/50007
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@1552 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
This makes it possible to remote debuggers to just add commands to the queue without having to request a break as well. As soon as any JavaScript executes the debugger commands will be processed and the response send to the remote debugger.
Currently hide this behind a flag (--debugger-auto-break) as the current command line debugger in Chrome is not designed for this new behaviour, whereas the new Chrome developer tools will use it.
Review URL: http://codereview.chromium.org/42173
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@1508 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
Changed the script break points to be able to handle both break points based on script names and script ids. When break points are set through a script id the position is relative to the script itself. This is different from the script break points set through script names where the line/coulmn offset is taken into account.
This has the side effect that function break points are not converted into script break points for named scripts.
Show the script id in the D8 shell debugger when listing all scripts using the 'scripts' command.
Review URL: http://codereview.chromium.org/40317
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@1468 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
Add the ability to have the host embedding V8 receive a callback in the V8 thread while V8 is processing a debug callback. When V8 is processing a debug callback the thread where V8 is executing is sitting in a tight loop processing debug commands until the continue command has been executed. In some embedding situations it is beneficial to be able to call back into the embedding host from the thread where V8 is sitting. The might have functions which needs to be called to complement the JavaScript debugging.
Using the uint16_t array to pass a void* is a temporary hack.
Review URL: http://codereview.chromium.org/20491
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@1318 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
Added a number of handle scopes to the debugger code to keep handles local to the function using them.
Fixed SetDebugEventListener to actually unregister when passed a NULL pointer. Previously this NULL pointer was wrapped in a Proxy.
BUG=1242702
Review URL: http://codereview.chromium.org/21347
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@1269 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
Changed the name of Runtime_GetPrototype to Runtime_DebugGetPrototype to indicate that it is a debugger related function and changed its implementation to do the correct __proto__ lookup.
Added some more information to the Map debug print.
Review URL: http://codereview.chromium.org/18658
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@1126 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
Added quoting of the name of the ref property using {"ref":1} instead of {ref:1}. The Chrome C++ JSON parser implementation requires quoted property names.
Changed the JSON format for non finite numbers. The previous formatting using NaN, Infinite and -Infinite caused the Chrome C++ JSON parser implementation to fail. Values "NaN", "Infinite" and "-Infinite" (incuding quotes) are now used.
Reverted changes to DebugLookupResultValue (runtime.cc) from http://codereview.chromium.org/17377. The change caused callback into Chrome with the current V8 context expected to have a DOM Window global object. This is not the case when the debugger context is the active context. This causes properties from interceptors and accessors to be reported as undefined in the debugger.
Review URL: http://codereview.chromium.org/18194
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@1101 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
instead of normal JSObjects.
This ensures that __proto__ and accessors on the Object prototype do
not interfere with catch scopes. Also, it fixes the bug that catch
variables were not DontDelete (issue 74).
Next step is to create special lookup routines for context extension
objects and remove the special handling of context extension objects
from the general javascript object lookup routines.
Review URL: http://codereview.chromium.org/18143
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@1091 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
Properties from interceptors are also reflected through PropertyMirror as the distinction did not make sense seen from a JavaScript debugging perspective. The isNative function on a PropertyMirror can be used to check whether a property is defined natively by the host (or V8).
Simplified the local property lookup in the debug runtime call to just call GetProperty as the property is known to be a local property.
Review URL: http://codereview.chromium.org/17377
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@1068 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
Here is a description of the background and design of split window in Chrome and V8:
https://docs.google.com/a/google.com/Doc?id=chhjkpg_47fwddxbfr
This change list splits the window object into two parts: 1) an inner window object used as the global object of contexts; 2) an outer window object exposed to JavaScript and accessible by the name 'window'. Firefox did it awhile ago, here are some discussions: https://wiki.mozilla.org/Gecko:SplitWindow. One additional benefit of splitting window in Chrome is that accessing global variables don't need security checks anymore, it can improve applications that use many global variables.
V8 support of split window:
There are a small number of changes on V8 api to support split window:
Security context is removed from V8, so does related API functions;
A global object can be detached from its context and reused by a new context;
Access checks on an object template can be turned on/off by default;
An object can turn on its access checks later;
V8 has a new object type, ApiGlobalObject, which is the outer window object type. The existing JSGlobalObject becomes the inner window object type. Security checks are moved from JSGlobalObject to ApiGlobalObject. ApiGlobalObject is the one exposed to JavaScript, it is accessible through Context::Global(). ApiGlobalObject's prototype is set to JSGlobalObject so that property lookups are forwarded to JSGlobalObject. ApiGlobalObject forwards all other property access requests to JSGlobalObject, such as SetProperty, DeleteProperty, etc.
Security token is moved to a global context, and ApiGlobalObject has a reference to its global context. JSGlobalObject has a reference to its global context as well. When accessing properties on a global object in JavaScript, the domain security check is performed by comparing the security token of the lexical context (Top::global_context()) to the token of global object's context. The check is only needed when the receiver is a window object, such as 'window.document'. Accessing global variables, such as 'var foo = 3; foo' does not need checks because the receiver is the inner window object.
When an outer window is detached from its global context (when a frame navigates away from a page), it is completely detached from the inner window. A new context is created for the new page, and the outer global object is reused. At this point, the access check on the DOMWindow wrapper of the old context is turned on. The code in old context is still able to access DOMWindow properties, but it has to go through domain security checks.
It is debatable on how to implement the outer window object. Currently each property access function has to check if the receiver is ApiGlobalObject type. This approach might be error-prone that one may forget to check the receiver when adding new functions. It is unlikely a performance issue because accessing global variables are more common than 'window.foo' style coding.
I am still working on the ARM port, and I'd like to hear comments and suggestions on the best way to support it in V8.
Review URL: http://codereview.chromium.org/7366
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@540 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
upper case. Moved it into the RelocInfo class together with the associated
is_xxx functions. Renamed is_xxx to IsXxx in the process.
Removed the exit_js_frame mode as it was no longer used.
Patch Set 2 renames RELOC_MODE_COUNT to NUMBER_OF_MODES and fixes a couple of lint errors.
Review URL: http://codereview.chromium.org/3186
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@354 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
