Recent

Author Topic: FpDebug 1.0  (Read 36136 times)

Martin_fr

  • Administrator
  • Hero Member
  • *
  • Posts: 9754
  • Debugger - SynEdit - and more
    • wiki
FpDebug 1.0
« on: June 23, 2021, 06:33:58 pm »
FpDebug and LazDebuggerFp have reached version 1.0.

This means on Windows and Linux, the upcoming Lazarus 2.2 will use this as the new default debugger.

People who have configurations from prior installations already have config files containing the gdb based debugger. Those config files are not changed, and people are advised to change their debugger settings accordingly (once they upgraded)


GDB based debuggers are still fully supported, and for Windows a modified gdb of version 9.2 will be included in the installer.

None of those changes apply to Mac users.


EDIT

FpDebug works with Dwarf2 and Dwarf3.
Make sure to also compile packages with the correct debug info, if you need to debug them.

Dwarf3 should be preferred, but if you switch between FpDebug and Gdb, you may want to choose Dwarf2. Gdb does have some Dwarf3 related crashes.

Dwarf2 can be "Dwarf2 and Sets"


EDIT

FpDebug can not yet be used in the following cases. If you have projects to which that applies, you can change to the gdb debugger on a per project base.
In "Project options" is a debugger page, where you can select the gdb debugger.

  • Debugging libraries
  • Using external *.dbg debug info files
« Last Edit: July 10, 2021, 03:17:05 am by Martin_fr »

howardpc

  • Hero Member
  • *****
  • Posts: 4144
Re: FpDebug 1.0
« Reply #1 on: June 23, 2021, 07:53:39 pm »
Martin, congratulations on getting the debuggers to this point of development and usability.
I know many Lazarus users would join me in thanking you, Marc (and others too, but you particularly) for all the months of work this milestone represents.

Martin_fr

  • Administrator
  • Hero Member
  • *
  • Posts: 9754
  • Debugger - SynEdit - and more
    • wiki
Re: FpDebug 1.0
« Reply #2 on: June 23, 2021, 08:12:05 pm »
thanking you, Marc (and others too, but you particularly)

Not to forget, Joost has also done some good parts. Thanks to him, there is some first ability to call functions in the debugger. (Object methods from bases in other units to not work / so sorry, but no TList.GetCount)
Also, this part is still alpha. Use at your peril.

Martin_fr

  • Administrator
  • Hero Member
  • *
  • Posts: 9754
  • Debugger - SynEdit - and more
    • wiki
Re: FpDebug 1.0
« Reply #3 on: June 23, 2021, 08:12:26 pm »

Igor Kokarev

  • Sr. Member
  • ****
  • Posts: 370
Re: FpDebug 1.0
« Reply #4 on: June 25, 2021, 03:40:23 pm »
Thanks, Martin!

BlueIcaro

  • Hero Member
  • *****
  • Posts: 791
    • Blog personal
Re: FpDebug 1.0
« Reply #5 on: June 25, 2021, 06:41:08 pm »
Thanks!!!.
One question. This debug supports remote debuging?

/Blueicaro

Martin_fr

  • Administrator
  • Hero Member
  • *
  • Posts: 9754
  • Debugger - SynEdit - and more
    • wiki
Re: FpDebug 1.0
« Reply #6 on: June 25, 2021, 06:53:19 pm »
Thanks!!!.
One question. This debug supports remote debuging?

No. For that gdb is still part of the installer.

If you need that on a per project base, then you can set a debugger per project.

Also
=> FpDebug is only for Intel/AMD. (And only Linux/Win)
=> If you run on ARM, then you need gdb.

There is no work on extending that yet (also it is on the "would be nice" list)

(
Well there is some contributed work going on for an avr version of it https://github.com/ccrause/lazarus
I have to check the state of it in Lazarus trunk
)

Max V. Terentiev

  • New Member
  • *
  • Posts: 30
Re: FpDebug 1.0
« Reply #7 on: June 27, 2021, 11:12:22 am »
Can new debugger evaluate properties with getters/setters ? This is very long awaited feature )

Martin_fr

  • Administrator
  • Hero Member
  • *
  • Posts: 9754
  • Debugger - SynEdit - and more
    • wiki
Re: FpDebug 1.0
« Reply #8 on: June 27, 2021, 11:58:20 am »
Can new debugger evaluate properties with getters/setters ? This is very long awaited feature )
Not, yet.

But, first progress in this direction has actually been made. Joost added "function calling in watches" (so a lot of functions currently are not avail for calling).
Afaik, Joost is now also looking into adding the requirements to the compiler.


The problem with properties has always been many fold.

The debugger can only access data, that the compiler provides in the debug info.
At current properties are not included in this. The compiler doesn't put the info in there.

To make it worse, the debug info format, does not even provide an official format for that.
But it allows to add proprietary data.

(Afaik) Joost is now working on adding such proprietary data.
So when he is done, that goes into the (then to be) next major fpc release.

Since FpDebug has function calling (though that needs to tested, and likely improved / but it is there), once Fpc writes the data, it will work.



Calling function in watches.

*** This is new and not much tested / If it crashes, report it. But do not complain about your IDE taking the current session to the grave ***

Must be enabled, in global debugger settings.
Must be enabled per watch.

Works only for
- plain functions (not methods)
- methods, if and only if, their function body (the actual code) is in the same unit, as the declaration of the variable holding the instance you are inspecting
  var a: TMyList // in unit42
  watch: a.GetBar();   // "function TMyList.GetBar()" must be declared and implemented in unit42
                            // if "a" is global, then your "current execution line" can be anywhere else
- must be called using ()
- must return an ordinal type (no strings yet)
- takes either no arguments, or only 2 or 3 arguments max (depends on OS)
- all arguments must be ordinal types

As I said, this is all very new. It's not yet indented for real use. But it is progress. There is actual work on the issue now.


piola

  • Full Member
  • ***
  • Posts: 118
  • Lazarus 2.2, 64bit on Windows 8.1 x64
Re: FpDebug 1.0
« Reply #9 on: June 29, 2021, 02:04:49 pm »
Can new debugger evaluate properties with getters/setters ? This is very long awaited feature )

Just a side question out of curiosity: Does Delphi support that?

devEric69

  • Hero Member
  • *****
  • Posts: 648
Re: FpDebug 1.0
« Reply #10 on: June 29, 2021, 02:18:58 pm »
Just a side question out of curiosity: Does Delphi support that?

AFAIK: Yes. And this is what Joost, Martin, ..., are working on ( getters/setters are functions and procedures to be evaluated in the debugger ).
use: Linux 64 bits (Ubuntu 20.04 LTS).
Lazarus version: 2.0.4 (svn revision: 62502M) compiled with fpc 3.0.4 - fpDebug \ Dwarf3.

marcov

  • Administrator
  • Hero Member
  • *
  • Posts: 11351
  • FPC developer.
Re: FpDebug 1.0
« Reply #11 on: June 29, 2021, 02:26:47 pm »
Delphi also has visualizers that improve the view of certain common classes like tlist/tstringlist:

http://docwiki.embarcadero.com/RADStudio/Sydney/en/Debugger_Visualizers

Martin_fr

  • Administrator
  • Hero Member
  • *
  • Posts: 9754
  • Debugger - SynEdit - and more
    • wiki
Re: FpDebug 1.0
« Reply #12 on: June 29, 2021, 05:40:39 pm »
Delphi also has visualizers that improve the view of certain common classes like tlist/tstringlist:

http://docwiki.embarcadero.com/RADStudio/Sydney/en/Debugger_Visualizers
The entire debugger frontend could do with a big redo/improvements...


Zaher

  • Hero Member
  • *****
  • Posts: 679
    • parmaja.org
Re: FpDebug 1.0
« Reply #13 on: July 08, 2021, 11:55:26 am »
Can I use it in my editor to debug simple pascal (one based program file .pas) or to debug some gnu compilers like c/c++?

Martin_fr

  • Administrator
  • Hero Member
  • *
  • Posts: 9754
  • Debugger - SynEdit - and more
    • wiki
Re: FpDebug 1.0
« Reply #14 on: July 08, 2021, 01:28:31 pm »
There is no stand-alone fpdebug (yet / nor will be in a while / nor will it necessarily have gdb compatible in/output).
So probably no.

Unless "your editor" is the editor you wrote, and you want to include the fpdebug package, as well as you have some front end to interact with it. (note that iirc fpdebug is gpl, not lgpl)


"c based" should be ok-ish.

That is it should be reading the dwarf info and be able to access the data just fine.

But it will display them pascal-ish. And expect watch input to be pascal.
E.g. Foo^.bar  rather than foo->bar

Both input and output are separated from the rest, and can be replaced with modules for other languages.... But currently there is only pascal. (And the interface they use may still change...)

« Last Edit: July 08, 2021, 01:34:04 pm by Martin_fr »

 

TinyPortal © 2005-2018