Chromium Code Reviews
chromiumcodereview-hr@appspot.gserviceaccount.com (chromiumcodereview-hr) | Please choose your nickname with Settings | Help | Chromium Project | Gerrit Changes | Sign out
(168)

Side by Side Diff: docs/debugger_protocol.md

Issue 1459823002: [Docs] Removed unused docs because they are moved to GitHub (Closed) Base URL: https://chromium.googlesource.com/v8/v8.git@master
Patch Set: Created 5 years, 1 month ago
Use n/p to move between diff chunks; N/P to move between comments. Draft comments are only viewable by you.
Jump to:
View unified diff | Download patch
« no previous file with comments | « docs/d8_on_android.md ('k') | docs/gdb_jit_interface.md » ('j') | no next file with comments »
Toggle Intra-line Diffs ('i') | Expand Comments ('e') | Collapse Comments ('c') | Show Comments Hide Comments ('s')
OLDNEW
(Empty)
1 # Introduction
2
3 V8 has support for debugging the JavaScript code running in it. There are two AP I's for this a function based API using JavaScript objects and a message based A PI using a JSON based protocol. The function based API can be used by an in-proc ess debugger agent, whereas the message based API can be used out of process as well.
4 **> The message based API is no longer maintained. Please ask in v8-users@google groups.com if you want to attach a debugger to the run-time.**
5
6 The debugger protocol is based on [JSON](http://www.json.org/)). Each protocol p acket is defined in terms of JSON and is transmitted as a string value. All pack ets have two basic elements `seq` and `type`.
7
8 ```
9 { "seq" : <number>,
10 "type" : <type>,
11 ...
12 }
13 ```
14
15 The element `seq` holds the sequence number of the packet. And element type is t he type of the packet. The type is a string value with one of the following valu es `"request"`, `"response"` or `"event"`.
16
17 A `"request"` packet has the following structure:
18
19 ```
20 { "seq" : <number>,
21 "type" : "request",
22 "command" : <command>
23 "arguments" : ...
24 }
25 ```
26
27 A `"response"` packet has the following structure. If `success` is true `body` w ill contain the response data. If `success` is false `message` will contain an e rror message.
28
29 ```
30 { "seq" : <number>,
31 "type" : "response",
32 "request_seq" : <number>,
33 "command" : <command>
34 "body" : ...
35 "running" : <is the VM running after sending this response>
36 "success" : <boolean indicating success>
37 "message" : <if command failed this property contains an error message>
38 }
39 ```
40
41 An `"event"` packet has the following structure:
42
43 ```
44 { "seq" : <number>,
45 "type" : "event",
46 "event" : <event name>
47 body : ...
48 }
49 ```
50
51 # Request/response pairs
52
53 ## Request `continue`
54
55 The request `continue` is a request from the debugger to start the VM running ag ain. As part of the `continue` request the debugger can specify if it wants the VM to perform a single step action.
56
57 ```
58 { "seq" : <number>,
59 "type" : "request",
60 "command" : "continue",
61 "arguments" : { "stepaction" : <"in", "next" or "out">,
62 "stepcount" : <number of steps (default 1)>
63 }
64 }
65 ```
66
67 In the response the property `running` will always be true as the VM will be run ning after executing the `continue` command. If a single step action is requeste d the VM will respond with a `break` event after running the step.
68
69 ```
70 { "seq" : <number>,
71 "type" : "response",
72 "request_seq" : <number>,
73 "command" : "continue",
74 "running" : true
75 "success" : true
76 }
77 ```
78
79
80 Here are a couple of examples.
81
82 ```
83 {"seq":117,"type":"request","command":"continue"}
84 {"seq":118,"type":"request","command":"continue","arguments":{"stepaction":"out" }}
85 {"seq":119,"type":"request","command":"continue","arguments":{"stepaction":"next ","stepcount":5}}
86 ```
87
88 ## Request `evaluate`
89
90 The request `evaluate` is used to evaluate an expression. The body of the result is as described in response object serialization below.
91
92 ```
93 { "seq" : <number>,
94 "type" : "request",
95 "command" : "evaluate",
96 "arguments" : { "expression" : <expression to evaluate>,
97 "frame" : <number>,
98 "global" : <boolean>,
99 "disable_break" : <boolean>,
100 "additional_context" : [
101 { "name" : <name1>, "handle" : <handle1> },
102 { "name" : <name2>, "handle" : <handle2> },
103 ...
104 ]
105 }
106 }
107 ```
108
109 Optional argument `additional_context` specifies handles that will be visible fr om the expression under corresponding names (see example below).
110
111 Response:
112
113 ```
114 { "seq" : <number>,
115 "type" : "response",
116 "request_seq" : <number>,
117 "command" : "evaluate",
118 "body" : ...
119 "running" : <is the VM running after sending this response>
120 "success" : true
121 }
122 ```
123
124 Here are a couple of examples.
125
126 ```
127 {"seq":117,"type":"request","command":"evaluate","arguments":{"expression":"1+2" }}
128 {"seq":118,"type":"request","command":"evaluate","arguments":{"expression":"a()" ,"frame":3,"disable_break":false}}
129 {"seq":119,"type":"request","command":"evaluate","arguments":{"expression":"[o.a ,o.b,o.c]","global":true,"disable_break":true}}
130 {"seq":120,"type":"request","command":"evaluate","arguments":{"expression":"obj. toString()", "additional_context": [{ "name":"obj","handle":25 }] }}
131 ```
132
133 ## Request `lookup`
134
135 The request `lookup` is used to lookup objects based on their handle. The indivi dual array elements of the body of the result is as described in response object serialization below.
136
137 ```
138 { "seq" : <number>,
139 "type" : "request",
140 "command" : "lookup",
141 "arguments" : { "handles" : <array of handles>,
142 "includeSource" : <boolean indicating whether the source will be included when script objects are returned>,
143 }
144 }
145 ```
146
147 Response:
148
149 ```
150 { "seq" : <number>,
151 "type" : "response",
152 "request_seq" : <number>,
153 "command" : "lookup",
154 "body" : <array of serialized objects indexed using their handle>
155 "running" : <is the VM running after sending this response>
156 "success" : true
157 }
158 ```
159
160 Here are a couple of examples.
161
162 ```
163 {"seq":117,"type":"request","command":"lookup","arguments":{"handles":"[1]"}}
164 {"seq":118,"type":"request","command":"lookup","arguments":{"handles":"[7,12]"}}
165 ```
166
167 ## Request `backtrace`
168
169 The request `backtrace` returns a backtrace (or stacktrace) from the current exe cution state. When issuing a request a range of frames can be supplied. The top frame is frame number 0. If no frame range is supplied data for 10 frames will b e returned.
170
171 ```
172 { "seq" : <number>,
173 "type" : "request",
174 "command" : "backtrace",
175 "arguments" : { "fromFrame" : <number>
176 "toFrame" : <number>
177 "bottom" : <boolean, set to true if the bottom of the stack is requested>
178 }
179 }
180 ```
181
182 The response contains the frame data together with the actual frames returned an d the toalt frame count.
183
184 ```
185 { "seq" : <number>,
186 "type" : "response",
187 "request_seq" : <number>,
188 "command" : "backtrace",
189 "body" : { "fromFrame" : <number>
190 "toFrame" : <number>
191 "totalFrames" : <number>
192 "frames" : <array of frames - see frame request for details>
193 }
194 "running" : <is the VM running after sending this response>
195 "success" : true
196 }
197 ```
198
199 If there are no stack frames the result body only contains `totalFrames` with a value of `0`. When an exception event is generated due to compilation failures i t is possible that there are no stack frames.
200
201 Here are a couple of examples.
202
203 ```
204 {"seq":117,"type":"request","command":"backtrace"}
205 {"seq":118,"type":"request","command":"backtrace","arguments":{"toFrame":2}}
206 {"seq":119,"type":"request","command":"backtrace","arguments":{"fromFrame":0,"to Frame":9}}
207 ```
208
209 ## Request `frame`
210
211 The request frame selects a new selected frame and returns information for that. If no frame number is specified the selected frame is returned.
212
213 ```
214 { "seq" : <number>,
215 "type" : "request",
216 "command" : "frame",
217 "arguments" : { "number" : <frame number>
218 }
219 }
220 ```
221
222 Response:
223
224 ```
225 { "seq" : <number>,
226 "type" : "response",
227 "request_seq" : <number>,
228 "command" : "frame",
229 "body" : { "index" : <frame number>,
230 "receiver" : <frame receiver>,
231 "func" : <function invoked>,
232 "script" : <script for the function>,
233 "constructCall" : <boolean indicating whether the function was called as constructor>,
234 "debuggerFrame" : <boolean indicating whether this is an in ternal debugger frame>,
235 "arguments" : [ { name: <name of the argument - missing of anonymous argument>,
236 value: <value of the argument>
237 },
238 ... <the array contains all the argumen ts>
239 ],
240 "locals" : [ { name: <name of the local variable>,
241 value: <value of the local variable>
242 },
243 ... <the array contains all the locals>
244 ],
245 "position" : <source position>,
246 "line" : <source line>,
247 "column" : <source column within the line>,
248 "sourceLineText" : <text for current source line>,
249 "scopes" : [ <array of scopes, see scope request bel ow for format> ],
250
251 }
252 "running" : <is the VM running after sending this response>
253 "success" : true
254 }
255 ```
256
257 Here are a couple of examples.
258
259 ```
260 {"seq":117,"type":"request","command":"frame"}
261 {"seq":118,"type":"request","command":"frame","arguments":{"number":1}}
262 ```
263
264 ## Request `scope`
265
266 The request scope returns information on a givne scope for a givne frame. If no frame number is specified the selected frame is used.
267
268 ```
269 { "seq" : <number>,
270 "type" : "request",
271 "command" : "scope",
272 "arguments" : { "number" : <scope number>
273 "frameNumber" : <frame number, optional uses selected frame if missing>
274 }
275 }
276 ```
277
278 Response:
279
280 ```
281 { "seq" : <number>,
282 "type" : "response",
283 "request_seq" : <number>,
284 "command" : "scope",
285 "body" : { "index" : <index of this scope in the scope chain. Inde x 0 is the top scope
286 and the global scope will always have the hi ghest index for a
287 frame>,
288 "frameIndex" : <index of the frame>,
289 "type" : <type of the scope:
290 0: Global
291 1: Local
292 2: With
293 3: Closure
294 4: Catch >,
295 "object" : <the scope object defining the content of the scope.
296 For local and closure scopes this is transie nt objects,
297 which has a negative handle value>
298 }
299 "running" : <is the VM running after sending this response>
300 "success" : true
301 }
302 ```
303
304 Here are a couple of examples.
305
306 ```
307 {"seq":117,"type":"request","command":"scope"}
308 {"seq":118,"type":"request","command":"scope","arguments":{"frameNumber":1,"numb er":1}}
309 ```
310
311 ## Request `scopes`
312
313 The request scopes returns all the scopes for a given frame. If no frame number is specified the selected frame is returned.
314
315 ```
316 { "seq" : <number>,
317 "type" : "request",
318 "command" : "scopes",
319 "arguments" : { "frameNumber" : <frame number, optional uses selected frame if missing>
320 }
321 }
322 ```
323
324 Response:
325
326 ```
327 { "seq" : <number>,
328 "type" : "response",
329 "request_seq" : <number>,
330 "command" : "scopes",
331 "body" : { "fromScope" : <number of first scope in response>,
332 "toScope" : <number of last scope in response>,
333 "totalScopes" : <total number of scopes for this frame>,
334 "scopes" : [ <array of scopes, see scope request above for f ormat> ],
335 }
336 "running" : <is the VM running after sending this response>
337 "success" : true
338 }
339 ```
340
341 Here are a couple of examples.
342
343 ```
344 {"seq":117,"type":"request","command":"scopes"}
345 {"seq":118,"type":"request","command":"scopes","arguments":{"frameNumber":1}}
346 ```
347
348 ## Request `scripts`
349
350 The request `scripts` retrieves active scripts from the VM. An active script is source code from which there is still live objects in the VM. This request will always force a full garbage collection in the VM.
351
352 ```
353 { "seq" : <number>,
354 "type" : "request",
355 "command" : "scripts",
356 "arguments" : { "types" : <types of scripts to retrieve
357 set bit 0 for native scripts
358 set bit 1 for extension scripts
359 set bit 2 for normal scripts
360 (default is 4 for normal scripts)>
361 "ids" : <array of id's of scripts to return. If this is not specified all scripts are requrned>
362 "includeSource" : <boolean indicating whether the source code should be included for the scripts returned>
363 "filter" : <string or number: filter string or script i d.
364 If a number is specified, then only the scr ipt with the same number as its script id will be retrieved.
365 If a string is specified, then only scripts whose names contain the filter string will be retrieved.>
366 }
367 }
368 ```
369
370 The request contains an array of the scripts in the VM. This information include s the relative location of the script within the containing resource.
371
372 ```
373 { "seq" : <number>,
374 "type" : "response",
375 "request_seq" : <number>,
376 "command" : "scripts",
377 "body" : [ { "name" : <name of the script>,
378 "id" : <id of the script>
379 "lineOffset" : <line offset within the containing re source>
380 "columnOffset" : <column offset within the containing resource>
381 "lineCount" : <number of lines in the script>
382 "data" : <optional data object added through t he API>
383 "source" : <source of the script if includeSourc e was specified in the request>
384 "sourceStart" : <first 80 characters of the script if includeSource was not specified in the request>
385 "sourceLength" : <total length of the script in charac ters>
386 "scriptType" : <script type (see request for values) >
387 "compilationType" : < How was this script compiled:
388 0 if script was compiled through the API
389 1 if script was compiled through eval
390 >
391 "evalFromScript" : <if "compilationType" is 1 this is th e script from where eval was called>
392 "evalFromLocation" : { line : < if "compilationType" is 1 this is the line in the script from where eval was called>
393 column : < if "compilationType" is 1 this is the column in the script from where eval was called>
394 ]
395 "running" : <is the VM running after sending this response>
396 "success" : true
397 }
398 ```
399
400 Here are a couple of examples.
401
402 ```
403 {"seq":117,"type":"request","command":"scripts"}
404 {"seq":118,"type":"request","command":"scripts","arguments":{"types":7}}
405 ```
406
407 ## Request `source`
408
409 The request `source` retrieves source code for a frame. It returns a number of s ource lines running from the `fromLine` to but not including the `toLine`, that is the interval is open on the "to" end. For example, requesting source from lin e 2 to 4 returns two lines (2 and 3). Also note that the line numbers are 0 base d: the first line is line 0.
410
411 ```
412 { "seq" : <number>,
413 "type" : "request",
414 "command" : "source",
415 "arguments" : { "frame" : <frame number (default selected frame)>
416 "fromLine" : <from line within the source default is line 0>
417 "toLine" : <to line within the source this line is not inclu ded in
418 the result default is the number of lines in the script>
419 }
420 }
421 ```
422
423 Response:
424
425 ```
426 { "seq" : <number>,
427 "type" : "response",
428 "request_seq" : <number>,
429 "command" : "source",
430 "body" : { "source" : <the source code>
431 "fromLine" : <actual from line within the script>
432 "toLine" : <actual to line within the script this line is not included in the source>
433 "fromPosition" : <actual start position within the script>
434 "toPosition" : <actual end position within the script>
435 "totalLines" : <total lines in the script>
436 }
437 "running" : <is the VM running after sending this response>
438 "success" : true
439 }
440 ```
441
442 Here are a couple of examples.
443
444 ```
445 {"seq":117,"type":"request","command":"source","arguments":{"fromLine":10,"toLin e":20}}
446 {"seq":118,"type":"request","command":"source","arguments":{"frame":2,"fromLine" :10,"toLine":20}}
447 ```
448
449 ## Request `setbreakpoint`
450
451 The request `setbreakpoint` creates a new break point. This request can be used to set both function and script break points. A function break point sets a brea k point in an existing function whereas a script break point sets a break point in a named script. A script break point can be set even if the named script is n ot found.
452
453 ```
454 { "seq" : <number>,
455 "type" : "request",
456 "command" : "setbreakpoint",
457 "arguments" : { "type" : <"function" or "script" or "scriptId" or "scri ptRegExp">
458 "target" : <function expression or script identification>
459 "line" : <line in script or function>
460 "column" : <character position within the line>
461 "enabled" : <initial enabled state. True or false, default is true>
462 "condition" : <string with break point condition>
463 "ignoreCount" : <number specifying the number of break point h its to ignore, default value is 0>
464 }
465 }
466 ```
467
468 The result of the `setbreakpoint` request is a response with the number of the n ewly created break point. This break point number is used in the `changebreakpoi nt` and `clearbreakpoint` requests.
469
470 ```
471 { "seq" : <number>,
472 "type" : "response",
473 "request_seq" : <number>,
474 "command" : "setbreakpoint",
475 "body" : { "type" : <"function" or "script">
476 "breakpoint" : <break point number of the new break point>
477 }
478 "running" : <is the VM running after sending this response>
479 "success" : true
480 }
481 ```
482
483 Here are a couple of examples.
484
485 ```
486 {"seq":117,"type":"request","command":"setbreakpoint","arguments":{"type":"funct ion,"target":"f"}}
487 {"seq":118,"type":"request","command":"setbreakpoint","arguments":{type:"script" ,"target":"test.js","line":100}}
488 {"seq":119,"type":"request","command":"setbreakpoint","arguments":{"type":"funct ion,"target":"f","condition":"i > 7"}}
489 ```
490
491
492 ## Request `changebreakpoint`
493
494 The request `changebreakpoint` changes the status of a break point.
495
496 ```
497 { "seq" : <number>,
498 "type" : "request",
499 "command" : "changebreakpoint",
500 "arguments" : { "breakpoint" : <number of the break point to clear>
501 "enabled" : <initial enabled state. True or false, default is true>
502 "condition" : <string with break point condition>
503 "ignoreCount" : <number specifying the number of break point h its }
504 }
505 ```
506
507 ## Request `clearbreakpoint`
508
509 The request `clearbreakpoint` clears a break point.
510
511 ```
512 { "seq" : <number>,
513 "type" : "request",
514 "command" : "clearbreakpoint",
515 "arguments" : { "breakpoint" : <number of the break point to clear>
516 }
517 }
518 ```
519
520 Response:
521
522 ```
523 { "seq" : <number>,
524 "type" : "response",
525 "request_seq" : <number>,
526 "command" : "clearbreakpoint",
527 "body" : { "type" : <"function" or "script">
528 "breakpoint" : <number of the break point cleared>
529 }
530 "running" : <is the VM running after sending this response>
531 "success" : true
532 }
533 ```
534
535 Here are a couple of examples.
536
537 ```
538 {"seq":117,"type":"request","command":"clearbreakpoint","arguments":{"type":"fun ction,"breakpoint":1}}
539 {"seq":118,"type":"request","command":"clearbreakpoint","arguments":{"type":"scr ipt","breakpoint":2}}
540 ```
541
542 ## Request `setexceptionbreak`
543
544 The request `setexceptionbreak` is a request to enable/disable breaks on all / u ncaught exceptions. If the "enabled" argument is not specify, the debuggee will toggle the state of the specified break type.
545
546 ```
547 { "seq" : <number>,
548 "type" : "request",
549 "command" : "setexceptionbreak",
550 "arguments" : { "type" : <string: "all", or "uncaught">,
551 "enabled" : <optional bool: enables the break type if true>
552 }
553 }
554 ```
555
556 In response, the break on exception property of the debuggee will be set accordi ngly, and the following response message will be dispatched to the debugger.
557
558 ```
559 { "seq" : <number>,
560 "type" : "response",
561 "request_seq" : <number>,
562 "command" : "setexceptionbreak",
563 “body” : { "type" : <string: "all" or "uncaught" corresponding to th e request.>,
564 "enabled" : <bool: true if the break type is currently enabl ed as a result of the request>
565 }
566 "running" : true
567 "success" : true
568 }
569 ```
570
571 Here are a few examples.
572
573 ```
574 {"seq":117,"type":"request","command":"setexceptionbreak","arguments":{"type":"a ll"}}
575 {"seq":118,"type":"request","command":" setexceptionbreak","arguments":{"type":" all",”enabled”:false}}
576 {"seq":119,"type":"request","command":" setexceptionbreak","arguments":{"type":" uncaught","enabled":true}}
577 ```
578
579 ## Request `v8flags`
580 The request v8flags is a request to apply the specified v8 flags (analogous to h ow they are specified on the command line).
581
582 ```
583 { "seq" : <number>,
584 "type" : "request",
585 "command" : "v8flags",
586 "arguments" : { "flags" : <string: a sequence of v8 flags just like those used on the command line>
587 }
588 }
589 ```
590
591 In response, the specified flags will be applied in the debuggee if they are leg al flags. Their effects vary depending on the implementation of the flag.
592
593 ```
594 { "seq" : <number>,
595 "type" : "response",
596 "request_seq" : <number>,
597 "command" : "v8flags",
598 "running" : true
599 "success" : true
600 }
601 ```
602
603 Here are a few examples.
604
605 ```
606 {"seq":117,"type":"request","command":"v8flags","arguments":{"flags":"--trace_gc —always_compact"}}
607 {"seq":118,"type":"request","command":" v8flags","arguments":{"flags":"--notrace _gc"}}
608 ```
609
610 ## Request `version`
611
612 The request `version` reports version of the running V8.
613
614 ```
615 { "seq" : <number>,
616 "type" : "request",
617 "command" : "version",
618 }
619 ```
620
621 Response:
622
623 ```
624 { "seq" : <number>,
625 "type" : "response",
626 "request_seq" : <number>,
627 "type" : "request",
628 "body" : { "V8Version": <string, version of V8>
629 }
630 "running" : <is the VM running after sending this response>
631 "success" : true
632 }
633 ```
634
635 Here is an example.
636
637 ```
638 {"seq":1,"type":"request","command":"version"}
639 {"seq":134,"request_seq":1,"type":"response","command":"version","success":true, "body":{"V8Version":"1.3.19 (candidate)"},"refs":[],"running":false}
640 ```
641
642 ## Request `disconnect`
643
644 The request `disconnect` is used to detach the remote debugger from the debuggee . This will trigger the debuggee to disable all active breakpoints and resumes execution if the debuggee was previously stopped at a break.
645
646 ```
647 { "seq" : <number>,
648 "type" : "request",
649 "command" : "disconnect",
650 }
651 ```
652
653 The only response for the `disconnect` request is the response to a connect requ est if the debugger is still able to get a response before the debuggee successf ully disconnects.
654
655 Here is an examples:
656
657 ```
658 {"seq":117,"type":"request","command":"disconnect"}
659 ```
660
661 ## Request `gc`
662 The request `gc` is a request to run the garbage collector in the debuggee.
663
664 ```
665 { "seq" : <number>,
666 "type" : "request",
667 "command" : "gc",
668 "arguments" : { "type" : <string: "all">,
669 }
670 }
671 ```
672
673 In response, the debuggee will run the specified GC type and send the following response message:
674
675 ```
676 { "seq" : <number>,
677 "type" : "response",
678 "request_seq" : <number>,
679 "command" : "gc",
680 “body” : { "before" : <int: total heap usage in bytes before the GC>,
681 "after" : <int: total heap usage in bytes after the GC>
682 }
683 "running" : true
684 "success" : true
685 }
686 ```
687
688 Here is an example.
689
690 ```
691 {"seq":117,"type":"request","command":"gc","arguments":{"type":"all"}}
692 ```
693
694 ## Request `listbreakpoints`
695
696 The request `listbreakpoints` is used to get information on breakpoints that may have been set by the debugger.
697
698 ```
699 { "seq" : <number>,
700 "type" : "request",
701 "command" : "listbreakpoints",
702 }
703 ```
704
705 Response:
706
707 ```
708 { "seq" : <number>,
709 "type" : "response",
710 "request_seq" : <number>,
711 "command" : "listbreakpoints",
712 "body" : { "breakpoints": [ { "type" : <string: "scriptId" or "scriptName".>,
713 "script_id" : <int: script id. On ly defined if type is scriptId.>,
714 "script_name" : <string: script name . Only defined if type is scriptName.>,
715 "number" : <int: breakpoint num ber. Starts from 1.>,
716 "line" : <int: line number of this breakpoint. Starts from 0.>,
717 "column" : <int: column number of this breakpoint. Starts from 0.>,
718 "groupId" : <int: group id of th is breakpoint.>,
719 "hit_count" : <int: number of time s this breakpoint has been hit. Starts from 0.>,
720 "active" : <bool: true if this breakpoint is enabled.>,
721 "ignoreCount" : <int: remaining numb er of times to ignore breakpoint. Starts from 0.>,
722 "actual_locations" : <actual locations of the breakpoint.>,
723 }
724 ],
725 "breakOnExceptions" : <true if break on all exceptio ns is enabled>,
726 "breakOnUncaughtExceptions" : <true if break on uncaught exc eptions is enabled>
727 }
728 "running" : <is the VM running after sending this response>
729 "success" : true
730 }
731 ```
732
733 Here is an examples:
734
735 ```
736 {"seq":117,"type":"request","command":"listbreakpoints"}
737 ```
738
739
740 ## Request `setvariablevalue`
741 This requests sets the value of a variable from the specified scope.
742
743 Request:
744
745 ```
746 { "seq" : <number>,
747 "type" : "request",
748 "command" : "setvariablevalue",
749 "arguments : { "name" : <string: variable name>,
750 "scope" : { "number" : <scope number>
751 "frameNumber" : <frame number, optional uses selec ted frame if missing>
752 }
753 }
754 }
755 ```
756
757 Response:
758
759 ```
760 { "seq" : <number>,
761 "type" : "response",
762 "request_seq" : <number>,
763 "type" : "request",
764 "body" : { "newValue": <object: mirror object of the new value> }
765 "running" : <is the VM running after sending this response>
766 "success" : true
767 }
768 ```
769
770 # Events
771
772 ## Event `break`
773
774 The event `break` indicate that the execution in the VM has stopped due to a bre ak condition. This can be caused by an unconditional break request, by a break p oint previously set, a stepping action have completed or by executing the `debug ger` statement in JavaScript.
775
776 ```
777 { "seq" : <number>,
778 "type" : "event",
779
780 "event" : "break",
781 "body" : { "invocationText" : <text representation of the stack frame>,
782 "sourceLine" : <source line where execution is stopped>,
783 "sourceColumn" : <column within the source line where execution is stopped>,
784 "sourceLineText" : <text for the source line where execution is st opped>,
785 "script" : { name : <resource name of the origin o f the script>
786 lineOffset : <line offset within the origin of the script>
787 columnOffset : <column offset within the orig in of the script>
788 lineCount : <number of lines in the script >
789 "breakpoints" : <array of break point numbers hit if any>
790 }
791 }
792 ```
793
794 Here are a couple of examples.
795
796 ```
797 {"seq":117,"type":"event","event":"break","body":{"functionName":"f","sourceLine ":1,"sourceColumn":14}}
798 {"seq":117,"type":"event","event":"break","body":{"functionName":"g","scriptData ":"test.js","sourceLine":12,"sourceColumn":22,"breakpoints":[1]}}
799 {"seq":117,"type":"event","event":"break","body":{"functionName":"h","sourceLine ":100,"sourceColumn":12,"breakpoints":[3,5,7]}}
800 ```
801
802 ## Event `exception`
803
804 The event `exception` indicate that the execution in the VM has stopped due to a n exception.
805
806 ```
807 { "seq" : <number>,
808 "type" : "event",
809 "event" : "exception",
810 "body" : { "uncaught" : <boolean>,
811 "exception" : ...
812 "sourceLine" : <source line where the exception was thrown>,
813 "sourceColumn" : <column within the source line from where the e xception was thrown>,
814 "sourceLineText" : <text for the source line from where the except ion was thrown>,
815 "script" : { "name" : <name of script>
816 "lineOffset" : <number>
817 "columnOffset" : <number>
818 "lineCount" : <number>
819 }
820
821 }
822 }
823 ```
824
825 # Response object serialization
826
827 Some responses contain objects as part of the body, e.g. the response to the eva luate request contains the result of the expression evaluated.
828
829 All objects exposed through the debugger is assigned an ID called a handle. This handle is serialized and can be used to identify objects. A handle has a certai n lifetime after which it will no longer refer to the same object. Currently the lifetime of handles match the processing of a debug event. For each debug event handles are recycled.
830
831 An object can be serialized either as a reference to a given handle or as a valu e representation containing the object content.
832
833 An object serialized as a reference looks follows this where `<handle>` is an in teger.
834
835 ```
836 {"ref":<handle>}
837 ```
838
839 For objects serialized as value they all contains the handle and the type of the object.
840
841 ```
842 { "handle" : <handle>,
843 "type" : <"undefined", "null", "boolean", "number", "string", "object", "fun ction" or "frame">
844 }
845 ```
846
847 In some situations special transient objects are created by the debugger. These objects are not really visible in from JavaScript, but are created to materializ e something inside the VM as an object visible to the debugger. One example of t his is the local scope object returned from the `scope` and `scopes` request. Tr ansient objects are identified by having a negative handle. A transient object c an never be retrieved using the `lookup` request, so all transient objects refer enced will be in the `refs` part of the response. The lifetime of transient obje cts is basically the request they are involved in.
848
849 For the primitive JavaScript types `undefined` and `null` the type describes the value fully.
850
851 ```
852 {"handle":<handle>,"type":"undefined"}
853 ```
854
855 ```
856 {"handle":<handle>,"type":"null"}
857 ```
858
859 For the rest of the primitive types `boolean`, `number` and `string` the value i s part of the result.
860
861 ```
862 { "handle":<handle>,
863 "type" : <"boolean", "number" or "string">
864 "value" : <JSON encoded value>
865 }
866 ```
867
868 Boolean value.
869
870 ```
871 {"handle":7,"type":"boolean","value":true}
872 ```
873
874 Number value.
875
876 ```
877 {"handle":8,"type":"number","value":42}
878 ```
879
880 String value.
881
882 ```
883 {"handle":9,"type":"string","value":"a string"}
884 ```
885
886 An object is encoded with additional information.
887
888 ```
889 { "handle" : <handle>,
890 "type" : "object",
891 "className" : <Class name, ECMA-262 property [[Class]]>,
892 "constructorFunction" : {"ref":<handle>},
893 "protoObject" : {"ref":<handle>},
894 "prototypeObject" : {"ref":<handle>},
895 "properties" : [ {"name" : <name>,
896 "ref" : <handle>
897 },
898 ...
899 ]
900 }
901 ```
902
903 The difference between the `protoObject` and the `prototypeObject` is that the ` protoObject` contains a reference to the actual prototype object (for which acce ssibility is not defined in ECMA-262, but in V8 it is accessible using the `__pr oto__` property) whereas the `prototypeObject` is the value of the `prototype` p roperty.
904
905 Here is an example.
906
907 ```
908 {"handle":3,"type":"object","className":"Object","constructorFunction":{"ref":4} ,"protoObject":{"ref":5},"prototypeObject":{"ref":6},"properties":[{"name":"a"," ref:7},{"name":"b","ref":8}]}
909 ```
910
911 An function is encoded as an object but with additional information in the prope rties `name`, `inferredName`, `source` and `script`.
912
913 ```
914 { "handle" : <handle>,
915 "type" : "function",
916 "className" : "Function",
917 "constructorFunction" : {"ref":<handle>},
918 "protoObject" : {"ref":<handle>},
919 "prototypeObject" : {"ref":<handle>},
920 "name" : <function name>,
921 "inferredName" : <inferred function name for anonymous functions>
922 "source" : <function source>,
923 "script" : <reference to function script>,
924 "scriptId" : <id of function script>,
925 "position" : <function begin position in script>,
926 "line" : <function begin source line in script>,
927 "column" : <function begin source column in script>,
928 "properties" : [ {"name" : <name>,
929 "ref" : <handle>
930 },
931 ...
932 ]
933 }
934 ```
OLDNEW
« no previous file with comments | « docs/d8_on_android.md ('k') | docs/gdb_jit_interface.md » ('j') | no next file with comments »

Powered by Google App Engine
This is Rietveld 408576698