Lazarus Debugger Implementation

From Lazarus wiki
Revision as of 23:03, 3 February 2021 by Martin (talk | contribs) (TDebuggerDataMonitor and TDebuggerDataSupplier - stack, watches, ....)

English (en)


This page provides an overview of how the debugger is implemented in the Lazarus IDE.

The debugger comprises the following parts:

The controls (run, step, stop buttons) and dialogs (watches, stack) in the IDE.
A set of base-classes defining the communication between the front-end and each back-end
Any code to control the debugged app, and retrieve/modify data from/in that app. The back-end may itself be split into an IDE back-end and an external back-end (e.g. gdb).


The code for the debugger frontend belongs currently directly to the IDE (to the project ide/lazarus.lpi). It is not a package of it's own.

Some of this code may one day be moved into a package. And maybe even introduce a package DebuggerFrontendIntf, to allow alternative 3rd party front-ends.

The code currently is located in

  • folder /debugger
  • folder /ide, files: debugmanager.pas and basedebugmanager.pas
  • folders ide/frames and debugger/frames for configuration settings.

BaseDebugManager is currently based on components\debuggerintf\dbgintfdebuggerbase.pp



TDebuggerIntf - main class

TDebuggerDataMonitor and TDebuggerDataSupplier - stack, watches, ....

The debugger can supply data like Threads, Stack, Locals, Watches... Any of this data is provided by a ___DataSupplier. On the IDE site to each Supplier, one ___DataMonitor is attached. The Supplier/Monitor concept was introduced to allow both sides to have their own, yet synchronized list of items for the list-entries.

For an example: Watches.

The IDE creates a Watch as "TIdeWatch". The Ide can stick any data to a watch that the IDE may require. For example watch-properties (display, enabled, ...) or streaming.

The back-end may need different information, such as internal details retrieved from the external-backend (gdb). So the back-end uses "TGDBMIWatches = class(TWatchesSupplier)". And other back-ends have their own sub-classes.

The supplier/monitor concept keeps the two lists synchronized. For Watches, the IDE side (the monitor) creates and deletes the entries. For Stack and locals, it is the back-end that creates/deletes entries.

When the IDE needs a value then the request is forwarded to the data-supplier. A value in this context can be anything read from any of the involved objects. The count of thread/stackframes is a value, the frame itself is a value (which is an object with multiple data fields). And the evaluated result of a watch is a value too.

All data is retrieved event driven. Asking for Stackcount, or watch-result will not return the value immediately. It will trigger its evaluation, and the data-supplier will sent an update event when the value (any value) becomes available.

For this to work, each value has a validity "TDebuggerDataState".

  • AWatch.Values[ThreadId, Stackframe].Value and AWatch.Values[ThreadId, Stackframe].Validity
  • In other cases validity is not exposed. Count may return 0, if it is not yet valid. (Maybe a TODO, to expose the validity? Just maybe.)

There is no rule how many update-events may be triggered before some value becomes valid. Any code listening to events from the monitor simply has to start over when it gets an event. Events may occur nested, code must protect itself again re-entrance in such a case.


GDB / GDBMI based



components\lazdebuggers\LazDebuggerLldb components\lazdebuggers\LazDebuggerFpLldb