From 34873b62cef9b03d8dd8b99b1a1d8f2fb7c0bfcf Mon Sep 17 00:00:00 2001 From: Sami Vaarala Date: Fri, 7 Aug 2015 00:23:53 +0300 Subject: [PATCH] Debugger document fixes - Clarification for heapptr dvalue - Mention dvalue debug transport in debugger doc --- doc/debugger.rst | 25 +++++++++++++++++++++---- 1 file changed, 21 insertions(+), 4 deletions(-) diff --git a/doc/debugger.rst b/doc/debugger.rst index b5257818..fa565738 100644 --- a/doc/debugger.rst +++ b/doc/debugger.rst @@ -66,7 +66,7 @@ To integrate debugger support into your target, you need to: target device and the Duktape debugger. The best transport depends on the target, e.g. a TCP socket, a serial link, or embedding debug data in an existing custom protocol. An example TCP debug transport is given in - ``examples/debug-trans-socket/duk_debug_trans_socket.c``. + ``examples/debug-trans-socket/duk_trans_socket.c``. * **Add code to attach a debugger**: call ``duk_debugger_attach()`` when it is time to start debugging. Duktape will pause execution and process debug @@ -118,6 +118,22 @@ The example debugger stuff includes: **While TCP is a good example transport, it is not a "standard" transport: the transport is always ultimately up to the user code.** +Example local debugger +---------------------- + +While a remote debug client is usually preferable, in some cases it may be +useful to terminate the debug connection in the same process as where Duktape +is running. From Duktape perspective a "local" debugger is just like a remote +one: a debug transport implementation hides the difference from Duktape. +There's an example debug transport with a local dvalue encoder/decoder: + +* ``examples/debug-trans-dvalue/`` + +The example transport hides the details of encoding and decoding dvalues, and +makes it easier to write a local debug client. The transport also serves as +an example for dealing with dvalues in C (the Node.js debugger has a similar +example for Javascript). + What Duktape doesn't provide ---------------------------- @@ -695,8 +711,9 @@ some cases: | 0x1d | lightfunc | Lightfunc flags, pointer length, | | | | pointer data (network endian) | +-----------------------+-----------+---------------------------------------+ -| 0x1e | heapptr | Pointer to a heap object (used by | -| | | DumpHeap, network endian) | +| 0x1e | heapptr | Pointer length, pointer data (network | +| | | endian); pointer to heap object, used | +| | | by DumpHeap | +-----------------------+-----------+---------------------------------------+ | 0x1f | reserved | | +-----------------------+-----------+---------------------------------------+ @@ -2460,7 +2477,7 @@ You may get the following when doing a DumpHeap:: ==17318== Syscall param write(buf) points to uninitialised byte(s) ==17318== at 0x5466700: __write_nocancel (syscall-template.S:81) - ==17318== by 0x427ADA: duk_debug_trans_socket_write (duk_debug_trans_socket.c:237) + ==17318== by 0x427ADA: duk_trans_socket_write_cb (duk_trans_socket.c:237) ==17318== by 0x403538: duk_debug_write_bytes.isra.11 (duk_debugger.c:379) ==17318== by 0x4036AC: duk_debug_write_strbuf (duk_debugger.c:463) [...]