Difference between revisions of "FpDebug"

From Lazarus wiki
Jump to navigationJump to search
Line 37: Line 37:
  
 
= General Debugging Issus =
 
= General Debugging Issus =
 +
 +
Those issues can not be fixed by the debugger alone. They need changes in FPC too. Some may also be affected by lack of support in DWARF.
  
 
== Properties ==
 
== Properties ==

Revision as of 20:40, 11 October 2019

English (en) русский (ru)

About

FpDebug is a debugger written in Pascal for Pascal.

In detail:

  • FpDebug is written in Pascal
  • FpDebug uses the DWARF debug info format
    • The current implementation is a subset of DWARF with support for DWARF version 2 and 3. However the "subset" is merely the state of implementation. The aim is to extend this to implement the as much of the standard as possible.
    • The current implementation covers the subset that is used by FPC
    • FpDebug has special implementations to deal with FPC specific DWARF usage (bugs, missing info, implementation details)

Different meanings of "FpDebug"

FpDebug can refer to

The package "FpDebug"

This is the engine of the debugger. It is not IDE specific. The package is used by several IDE backends:

  • LLDB Debugger (with fpdebug): This debugger uses LLDB as a backend. In order to display Pascal-style results, it uses the "fpdebug" engine to show locals/watches.
  • GNU Debugger (with fpdebug): Using GDB for stepping/breakpoints/... and FpDebug for watches.
  • FpDebug internal Dwarf debugger: Pure FpDebug. Stepping,Running,Breakpoint,Watches,Locals,Stack....

FpDebug as reference to the IDE backend

The actual name of the IDE backend is LazDebuggerFp. This is the name of the Package that needs to be installed to use the debugger. However as seen above, in none technical context (such as captions in the IDE) this is referred to as "FpDebug ..."

Other FpDebug projects

The name is used for another project with the same goal.

Installation in the IDE

Install the package LazDebuggerFp

General Debugging Issus

Those issues can not be fixed by the debugger alone. They need changes in FPC too. Some may also be affected by lack of support in DWARF.

Properties

Properties are one of the most wanted features for (any of) the debugger(s). Here is why they can not yet be inspected, and why it will still be a good while before this happens.

Before going into details: For "Properties without getter function" (i.e., "with direct field access") FPC (as means to a workaround of the issue) currently adds an entry for a variable with the property name. This means such properties can be displayed. They can also be written by the debugger (if the debugger supports changing data), and if they are written this is done bypassing any Setter procedure, since the debugger has no clue there even is a setter.

There are several missing pieces for allowing the debugger to show (and maybe modify) properties.

  • The debugger needs support to call functions
  • FPC needs a way to actually add info about the "properties" to the debug info.

As for calling function. This may just be missing implementation in the debugger. This has not yet been investigated in any more depth. It may or may not require additional info in the DWARF generated by FPC

As for adding "properties" to the debug info: DWARF (at least version 2 and 3 / not checked 4 or 5) does not actually have any way to encode this info. Consequently FPC currently does not add it either.

In case that DWARF does not add this in time, DWARF allows for vendor specific data (afaik). Up until now, no debugger would have known about any "private fpc data", so there was no point. In future such data could be agreed between FPC and FpDebug. But that is still a good way off. FpDebug does not even do function calling yet.


Strings (vs PChar and Array of Char)

Originally DWARF had no concept to encode strings. This has been added in DWARF 4 (need verification), but not yet been investigated for usability with FPC. Also FPC currently only implements DWARF 2 and 3 (with first steps towards version 4).

This leaves only 2 ways to encode a string in DWARF.

  • As pointer to char
  • As array of char

Which one is used depends on the version of FPC, and if DWARF 2 or 3 is used.

If it is "pointer to char", then this makes in indistinguishable from actual PChar. This is the reason all debuggers in Lazarus sometimes for a watch like "SomeString[4]" show the result "PChar: 'a'; String: 'b'". Because PChar is zero-based and string one-based, the index "4" can mean the 4th or the 5th char.

Recent FPC use the "array of char" when they generate DWARF 3. In that they have (currently) implementation detail differences between how they encode strings and real array of char. (Such as the omission of an optional/redundant bit of information. In this case: DW_AT_byte_stride). Those details are meaningless from the point of any other debugger, but FpDebug can detect them as it knows about those implementation details. Of course this is extremely fragile, the next version of FPC can always change this.

In a similar way FPC handles ShortStrings internally as record, and encodes them as this. Again distinguishing this is down to implementation details.


Scope / Variable search order (Nested Functions, Other Units)

Status