endb.rst 6.6 KB

123456789101112131415161718192021222324252627282930313233343536373839404142434445464748495051525354555657585960616263646566676869707172737475767778798081828384858687888990919293949596979899100101102103104105106107108109110111112113114115116117118119120121122123124125126127128129130131132133134135136137138139140141142143144145146147148149150151152153154155156157158159160161162163164165166167168169170171172173174175176177178179180181182183184185186187188189190191192193194195196197198199200201202203204
  1. ==============================================
  2. Embedded Nim Debugger (ENDB) User Guide
  3. ==============================================
  4. :Author: Andreas Rumpf
  5. :Version: |nimversion|
  6. .. contents::
  7. **WARNING**: ENDB is not maintained anymore! Please help if you're interested
  8. in this tool.
  9. Nim comes with a platform independent debugger -
  10. the Embedded Nim Debugger (ENDB). The debugger is
  11. *embedded* into your executable if it has been
  12. compiled with the ``--debugger:on`` command line option.
  13. This also defines the conditional symbol ``ENDB`` for you.
  14. Note: You must not compile your program with the ``--app:gui``
  15. command line option because then there would be no console
  16. available for the debugger.
  17. If you start your program the debugger will immediately show
  18. a prompt on the console. You can now enter a command. The next sections
  19. deal with the possible commands. As usual in Nim in all commands
  20. underscores and case do not matter. Optional components of a command
  21. are listed in brackets ``[...]`` here.
  22. General Commands
  23. ================
  24. ``h``, ``help``
  25. Display a quick reference of the possible commands.
  26. ``q``, ``quit``
  27. Quit the debugger and the program.
  28. <ENTER>
  29. (Without any typed command) repeat the previous debugger command.
  30. If there is no previous command, ``step_into`` is assumed.
  31. Executing Commands
  32. ==================
  33. ``s``, ``step_into``
  34. Single step, stepping into routine calls.
  35. ``n``, ``step_over``
  36. Single step, without stepping into routine calls.
  37. ``f``, ``skip_current``
  38. Continue execution until the current routine finishes.
  39. ``c``, ``continue``
  40. Continue execution until the next breakpoint.
  41. ``i``, ``ignore``
  42. Continue execution, ignore all breakpoints. This effectively quits
  43. the debugger and runs the program until it finishes.
  44. Breakpoint Commands
  45. ===================
  46. ``b``, ``setbreak`` [fromline [toline]] [file]
  47. Set a new breakpoint for the given file
  48. and line numbers. If no file is given, the current execution point's
  49. filename is used. If the filename has no extension, ``.nim`` is
  50. appended for your convenience.
  51. If no line numbers are given, the current execution point's
  52. line is used. If both ``fromline`` and ``toline`` are given the
  53. breakpoint contains a line number range. Some examples if it is still
  54. unclear:
  55. * ``b 12 15 thallo`` creates a breakpoint that
  56. will be triggered if the instruction pointer reaches one of the
  57. lines 12-15 in the file ``thallo.nim``.
  58. * ``b 12 thallo`` creates a breakpoint that
  59. will be triggered if the instruction pointer reaches the
  60. line 12 in the file ``thallo.nim``.
  61. * ``b 12`` creates a breakpoint that
  62. will be triggered if the instruction pointer reaches the
  63. line 12 in the current file.
  64. * ``b`` creates a breakpoint that
  65. will be triggered if the instruction pointer reaches the
  66. current line in the current file again.
  67. ``breakpoints``
  68. Display the entire breakpoint list.
  69. ``disable`` <identifier>
  70. Disable a breakpoint. It remains disabled until you turn it on again
  71. with the ``enable`` command.
  72. ``enable`` <identifier>
  73. Enable a breakpoint.
  74. Often it happens when debugging that you keep retyping the breakpoints again
  75. and again because they are lost when you restart your program. This is not
  76. necessary: A special pragma has been defined for this:
  77. The ``breakpoint`` pragma
  78. -------------------------
  79. The ``breakpoint`` pragma is syntactically a statement. It can be used
  80. to mark the *following line* as a breakpoint:
  81. .. code-block:: Nim
  82. write("1")
  83. {.breakpoint: "before_write_2".}
  84. write("2")
  85. The name of the breakpoint here is ``before_write_2``. Of course the
  86. breakpoint's name is optional - the compiler will generate one for you
  87. if you leave it out.
  88. Code for the ``breakpoint`` pragma is only generated if the debugger
  89. is turned on, so you don't need to remove it from your source code after
  90. debugging.
  91. The ``watchpoint`` pragma
  92. -------------------------
  93. The ``watchpoint`` pragma is syntactically a statement. It can be used
  94. to mark a location as a watchpoint:
  95. .. code-block:: Nim
  96. var a: array[0..20, int]
  97. {.watchpoint: a[3].}
  98. for i in 0 .. 20: a[i] = i
  99. ENDB then writes a stack trace whenever the content of the location ``a[3]``
  100. changes. The current implementation only tracks a hash value of the location's
  101. contents and so locations that are not word sized may encounter false
  102. negatives in very rare cases.
  103. Code for the ``watchpoint`` pragma is only generated if the debugger
  104. is turned on, so you don't need to remove it from your source code after
  105. debugging.
  106. Due to the primitive implementation watchpoints are even slower than
  107. breakpoints: After *every* executed Nim code line it is checked whether the
  108. location changed.
  109. Data Display Commands
  110. =====================
  111. ``e``, ``eval`` <exp>
  112. Evaluate the expression <exp>. Note that ENDB has no full-blown expression
  113. evaluator built-in. So expressions are limited:
  114. * To display global variables prefix their names with their
  115. owning module: ``nim1.globalVar``
  116. * To display local variables or parameters just type in
  117. their name: ``localVar``. If you want to inspect variables that are not
  118. in the current stack frame, use the ``up`` or ``down`` command.
  119. Unfortunately, only inspecting variables is possible at the moment. Maybe
  120. a future version will implement a full-blown Nim expression evaluator,
  121. but this is not easy to do and would bloat the debugger's code.
  122. Since displaying the whole data structures is often not needed and
  123. painfully slow, the debugger uses a *maximal display depth* concept for
  124. displaying.
  125. You can alter the maximal display depth with the ``maxdisplay``
  126. command.
  127. ``maxdisplay`` <natural>
  128. Sets the maximal display depth to the given integer value. A value of 0
  129. means there is no maximal display depth. Default is 3.
  130. ``o``, ``out`` <filename> <exp>
  131. Evaluate the expression <exp> and store its string representation into a
  132. file named <filename>. If the file does not exist, it will be created,
  133. otherwise it will be opened for appending.
  134. ``w``, ``where``
  135. Display the current execution point.
  136. ``u``, ``up``
  137. Go up in the call stack.
  138. ``d``, ``down``
  139. Go down in the call stack.
  140. ``stackframe`` [file]
  141. Displays the content of the current stack frame in ``stdout`` or
  142. appends it to the file, depending on whether a file is given.
  143. ``callstack``
  144. Display the entire call stack (but not its content).
  145. ``l``, ``locals``
  146. Display the available local variables in the current stack frame.
  147. ``g``, ``globals``
  148. Display all the global variables that are available for inspection.