FpGdbmiDebugger

From Free Pascal wiki
Jump to navigationJump to search
Warning-icon.png

Warning: FpGdbmiDebugger is still in alpha Development. It is advised not to use it for production. While using FpGdbmiDebugger problems including (but not limited to) the following may occur:

  • Crashes of the IDE or Debugger
  • Incorrect behaviour of the IDE or debugger
  • Display of incorrect Values

Light bulb  Note: FpGdbmiDebugger does not yet fix any of the following issues:

  • Properties can still not be shown
  • Watches can not call functions
  • Strings can not be distinguished from pchar
  • open array (in function params) are not handled




About

FpGdbmiDebugger is an extension of the GdbmiDebugger used by the IDE. Both debuggers use GDB.

FpGdbmiDebugger is intended to keep GDB as a back-end, so it can later be extended to use gdbserver for remote debugging. (An additional debugger that does not depend on GDB will also be developed, and like FpGdbmiDebugger, it will be based on the FpDebug package)

FpGdbmiDebugger is designed to perform some tasks without needing GDB:

  • Reading Line-Info, for displaying the blue gutter dots (working)
  • Reading Dwarf to evaluate Locals and watches (partly done)
    Reading data from the debuggee is done via gdb memread, but does not need gdb to have knowledge of Pascal values. Except on Windows where data can be read directly.
  • Reading Stackframes/traces (not yet done)
  • Disassemble (not yet done)

FpGdbmiDebugger is not intended to perform execution control directly (this is left to gdb), such as stepping, and running between breakpoints. (For this there will be a gdb free debugger)

Testing

See progress for which features are implemented. Any feature not mentioned should be assumed not yet to be implemented.

Do NOT report any unimplemented features.

To verify displayed watch values, a menu entry "Display GDB instead of FPDebug values" is available in the run menu (when the package is installed). This will be only while the package is in development.

To test FpGdbmiDebugger, install the package components/lazdebuggers/lazdebbugerfpgdbmi.lpk Then go to Menu: Tools > Options > Debugger. Select "GNU debugger (with fpdebug)".

There is also a testcase in that directory. Please read the comments in the *.sample files.

Progress

Warning-icon.png

Warning: FpGdbmiDebugger only works with Dwarf 2 (+ dwarfsets). Do not use external symbol files

The following features should work

Code line indicators (blue dots in gutter)

Locals

Improvements over the GDB based version:

  • Locals show values for types based on an internal pointer (string, object, dyn array). GDB shows only the address in the internal pointer

Not yet implemented:

  • currency type variables are incorrectly displayed
  • "self" is shown as "this"

Watches (partial)

Watches that are not implemented are handed to the normal GDB based evaluation, and the result will be prefixed with "{GDB:}"

Watches include hint evaluation, and debug-inspector.


Improvements over the GDB based version:

Not yet implemented:

  • currency variables are incorrectly displayed
  • Strings are handled the same as on normal GDB (handled an PChar). s[1] will display result for string and for pchar.
  • unitname.identifier
  • Any expression, or operator that is not listed in the below section. (May be forwarded to gdb, or give an error)
  • Error checking. Expressions that result in an error, may be forwarded to GDB, instead of displaying an error generated by fpdebug.
  • overflow checking. See below
  • Setting in the watch properties:
    • RepeatCount for watches is not implemented
    • DisplayFormats (default, pointer, hex, structure, mem dump) are partly implemented

The following expressions can be evaluated (if not listed, then it is not implemented)

  • simple terms (just an identifier)
  • typecasts
  • @ and ^ (address of and deref)
  • "^TFoo(x)" typecast x, as pointer to TFoo
  • () bracketed expression "a*(b+c)"
  • [] index for arrays, pointers, and pchar
  • . Foo.Bar access of members
  • constant numbers in decimal, hex ($), oct (&), bin (%)
  • +-*/ for int and float
  • +- for pointer+int
  • div for int
  • = <> < > <= >= for int and float

Internal details

  • All calculations are currently done without overflow checking. Overflown results will be used without indication of this.
  • @ currently returns typed pointers in the debugger. This matters for (@WordVar+2)^ , which increments by 2 words (4 bytes).
  • Fields in objects are ordered by base-class last. This means that in Foo:TFoo fields declared in TFoo are shown before fields in TObject (base). As a result field order does not represent memory layout (not sure if it actually is guaranteed with gdb).

Setting in the watch properties:

  • "Use instance class" is implemented

Implementation notes

FpGdbmiDebugger reads the dwarf info directly from the exe. This means both (gdb and fpdebug) read this info. For large projects this adds a few seconds to the debugger startup time.

FpGdbmiDebugger uses this info to determine the type-info associated with a watch, and its location in memory.

  • On Windows, FpGdbmiDebugger can attach as a 2nd debugger to an application that is already being debugged by gdb. Therefore FpGdbmiDebugger can use the Windows API to read memory from the debuggee
  • On other platforms, FpGdbmiDebugger issues "read memory" requests to gdb. This still means that gdb does NOT have to evaluate type-info. It only reads raw memory.

In terms of speed: on windows there is a huge speed improvement. On Linux (despite a flood of mem read commands done via gdb) the speed-up is only minimal.

On my PC (may be totally different on others) FpGdbmiDebugger on Windows reads watches (depending on type) in average in less than 10% of the time used by GdbmiDebugger. On Linux FpGdbmiDebugger takes 80% of the time used by GdbmiDebugger.

This is NOT compared to gdb itself. There are other differences contributing to this timings. Such as implementation detail in GdbmiDebugger, which needs avg 2.7 calls to gdb for one watch. And time used due to communication of the 2 processes via pipes (suspected to take some time on win, but not sure).

Feedback

Use the lazarus mail list please / Do not report on mantis yet.