Lazarus

Using the Lazarus IDE => Debugger => Topic started by: Martin_fr on October 13, 2019, 05:59:40 pm

Title: Testers wanted: FpDebug on Linux and Windows
Post by: Martin_fr on October 13, 2019, 05:59:40 pm
It is time to get some feedback on how FpDebug behaves in the wild.

If you want to test it, you need:
- Lazarus 2.1  revision 62049 (dated 13 Oct 2019) or higher/later
- Fpc any version that above Lazarus works with.
  If you use FPC trunk, you should aim for revision 43183 or higher.
     earlier trunk will cause bad results inspecting bitpacked arrays
     3.0.4 is fine
     3.2 may depend on what gets merged when, and FpDebug may need amendments if certain fpc fixes are merged.

As for what to expect:  https://wiki.lazarus.freepascal.org/FpDebug

It is recommended to test this with DWARF-3
However DWARF-2 is also supported. Please mention which one you tested.

When reporting back:
- Your Lazarus and FPC version/revision.
- Your OS (with version and 32 or 64 bit)
- Your IDE is 32 or 64 bit
- Your FPC is 32 or 64 bit
- Your target app is 32 or 64 bit (and indicate if it was cross compiled, by an FPC with different bitness)
- In case something failed, log output of (or preferably, a reproducible testcase)
  lazarus.exe   --debug-log=file   --log-enable=DBG_STATE,DBG_DATA_MONITORS,DBG_ERRORS,DBG_VERBOSE,DBG_WARNINGS,DBG_BREAKPOINTS,DBG_FPDEBUG_VERBOSE,FPDBG_BREAKPOINT_ERRORS,FPDBG_BREAKPOINTS

Thank you

Title: Re: Testers wanted: FpDebug on Linux and Windows
Post by: Thaddy on October 13, 2019, 06:13:05 pm
Will do for 3.2 and trunk.
Title: Re: Testers wanted: FpDebug on Linux and Windows
Post by: ccrause on October 13, 2019, 09:18:35 pm
I'll start using it on Linux 64 with FPC 3.0.4 and trunk.

Are there any plans to expand FpDebug to support remote debugging (gdb remote serial protocol) of AVR? I guess the key additions would be a remote communication layer and an AVR disassembler.
Title: Re: Testers wanted: FpDebug on Linux and Windows
Post by: Martin_fr on October 13, 2019, 09:42:13 pm
Are there any plans to expand FpDebug to support remote debugging (gdb remote serial protocol) of AVR? I guess the key additions would be a remote communication layer and an AVR disassembler.

No, no plans for gdb protocol.

Other CPU... Probably depend on contribution.

A FpDebug Server (for remote debugging to platform on which fpdebug runs....) will probably come. There already is some code that was started ages ago. But then the FpDebug Server must run on the target.
Also this will be a while... Plenty of other stuff before.

Same for a command line interface. Some prove of concept code exists, but may need to be fixed to be able to compile.

---------------------
About gdb...

There is LazDebuggerFpGDBMI.
Which is gdb, but watches and locals are done by fpdebug (using gdb to read the memory).

Since the fpdebug engine (and all the dwarf for watches) is a package of its own, anyone who wants can start a debugger that implements the gdb protocol and uses the fpdebug classes to handle dwarf.

Or translate LazDebuggerFpGDBMI to use gdbserver.
That should be easy, since it just needs to insert the commands to gdb that set the remote.... (and maybe async gdb commands)
Title: Re: Testers wanted: FpDebug on Linux and Windows
Post by: ccrause on October 14, 2019, 01:54:38 pm
Or translate LazDebuggerFpGDBMI to use gdbserver.
That should be easy, since it just needs to insert the commands to gdb that set the remote.... (and maybe async gdb commands)
My preference is to move away from gdb since it needs a patch (which has been around since 2016) to work properly with the separate memory spaces of avr.
Title: Re: Testers wanted: FpDebug on Linux and Windows
Post by: Martin_fr on October 14, 2019, 02:14:58 pm
My preference is to move away from gdb since it needs a patch (which has been around since 2016) to work properly with the separate memory spaces of avr.
Moved to https://forum.lazarus.freepascal.org/index.php/topic,47073.msg336382.html#msg336382
Title: Re: Testers wanted: FpDebug on Linux and Windows
Post by: devEric69 on October 17, 2019, 01:42:28 pm
Sorry, but I'm discovering FpDebug. So, hoping to be able to participate to its test:
- I've installed its package (components\fpdebug\fpdebug.lpk, version 0.0), in Lazarus 2.0.2 + FPC 3.0.4.
- in my project options, I use "Dwarf 3".

==> now, my stupid questions:
a) in the environment options, debugger, I must select "LLDB debugger (with fpdebug beta)" ?
b) below, do I leave "$(LazarusDir)\mingw\$(TargetCPU)-$(TargetOS)\bin\gdb.exe" ?

Thank you for the clarifications.
Title: Re: Testers wanted: FpDebug on Linux and Windows
Post by: Martin_fr on October 17, 2019, 06:35:25 pm
On Linux / Windows

You need to install the package LazDebuggerFp
and then you find "fpdebug .... " in the list. and you do not need gdb (nor any other external exe)

Note that in 2.0.x you can use it, but it has known bugs. And is slower. Testing should be done with Lazarus trunk


On Mac, the standalone fp debug does not work, but you can install LazdebuggerFPlldb, and then change from gdb to lldb
Title: Re: Testers wanted: FpDebug on Linux and Windows
Post by: devEric69 on October 18, 2019, 08:41:50 am
Thank you.
Title: Re: Testers wanted: FpDebug on Linux and Windows
Post by: zeljko on October 19, 2019, 09:30:41 am
Not so detailed test but it works pretty good (and much faster than gdb).
One small problem: when program finished there's no dialog "Execution stopped" like it popup when stop program with gdb as debugger.
EDIT: Fedora 29, 64bit, fpc-3.0.4 + lazarus trunk r62073
Title: Re: Testers wanted: FpDebug on Linux and Windows
Post by: Martin_fr on October 25, 2019, 03:00:52 pm
One small problem: when program finished there's no dialog "Execution stopped" like it popup when stop program with gdb as debugger.
I just tested (on windows though) and the dialog appears.

Have you checked in the Tools > Options > Debugger > General, that the checkbox is set? (this is not part of the backend config)

EDIT:
On Fedora 28 it works too
Title: Re: Testers wanted: FpDebug on Linux and Windows
Post by: Martin_fr on December 08, 2019, 06:02:43 pm
I put together a feature/status list (according to memory):
https://wiki.lazarus.freepascal.org/Debugger_Status
Title: Re: Testers wanted: FpDebug on Linux and Windows
Post by: avra on December 09, 2019, 03:53:42 pm
I put together a feature/status list (according to memory):
https://wiki.lazarus.freepascal.org/Debugger_Status

Thanks! Really much appreciated   :D
Title: Re: Testers wanted: FpDebug on Linux and Windows
Post by: Pascal on March 06, 2020, 01:32:54 pm
Does not work in 32bit Lazarus debugging 64bit App.
With gdb i could set the 64bit gdb in the options.

But this is obvius as the debugger is integrated in the 32bit Lazarus App!
A message dialog would be nice in this case ;-) Instead of doing nothing!

Pascal
Title: Re: Testers wanted: FpDebug on Linux and Windows
Post by: Martin_fr on March 06, 2020, 01:47:55 pm
Does not work in 32bit Lazarus debugging 64bit App.

Yes, that is known. At some time in the future an external/remote fpdebug.exe may be created.
Title: Re: Testers wanted: FpDebug on Linux and Windows
Post by: Igor Kokarev on July 28, 2020, 10:03:54 am
Martin,

Thanks for FpDebug!

Will FpDebug support external symbols (-Xg)?

We use -Xg in our app to link statically some GCC .o libraries.
Title: Re: Testers wanted: FpDebug on Linux and Windows
Post by: Martin_fr on July 28, 2020, 11:17:43 am
Will FpDebug support external symbols (-Xg)?

We use -Xg in our app to link statically some GCC .o libraries.

It should already do (at least in basic cases). I tested on Windows, but IIRC should be Linux too.

Note that debugging in libraries (dll/so) files is still work in progress. You have to test and see what works.
Title: Re: Testers wanted: FpDebug on Linux and Windows
Post by: wp on July 28, 2020, 12:13:13 pm
With my current gdb issues with console applications I finally decided to give fpdebug a try. And I must say I am extraordinarily surprised. It's almost like working with Delphi finally! Fly-over hints of properties? No problem (well, mostly...). 10 to 20 seconds waiting before the FileDialog opens in the debugger? No problem. I think i can do 90% of my debug work with it.

For those who like myself are confused by the many debugger packages available in the standard installation here are the steps that I took to make it work

- Go to "Package" > "Install/Uninstall packages". Make sure that LazDebuggerFp is installed (if not, install the package).
- Go to "Tools" > "Options" > "Debugger". In the gray combobox "Debugger type and paths" which usually displays "GNU debugger (gdb)", select "FpDebug standard Dwarf debugger (beta)".
- After compilation of a project you will be prompted to select which kind of dwarf debugging informations is too be used. The selection is written to the project file. (I hope permanent selection here is not a problem when the project is passed to others, like in my forum posts)

@Martin: There is also a package fpdebug. It is not installed on my systems. Is it needed?
Title: Re: Testers wanted: FpDebug on Linux and Windows
Post by: Martin_fr on July 28, 2020, 12:20:36 pm
With my current gdb issues with console applications I finally decided to give fpdebug a try. And I must say I am extraordinarily surprised. It's almost like working with Delphi finally! Fly-over hints of properties? No problem (well, mostly...). 10 to 20 seconds waiting before the FileDialog opens in the debugger? No problem. I think i can do 90% of my debug work with it.
Properties (or the working subset of them) are actually not fpdebug specific.

They are stabs vs dwarf. However fpdebug only supports dwarf, so you were forced to select that.

With dwarf, fpc writes info for properties that read the field directly (that is there is no getter proc).
When using dwarf, gdb will show the same set of properties.
https://wiki.lazarus.freepascal.org/GDB_Debugger_Tips#Properties

However, with FpDebug you can use "Dwarf 3" and get the names in stack/locals/... in normal case as declared (instead of all uppercase).

Gdb does dwarf-3, but  dwarf3 increases the risk of gdb crashing.

Quote
@Martin: There is also a package fpdebug. It is not installed on my systems. Is it needed?
Its used by LazDebuggerFp. So its compiled in.

But it does not need to be installed.
Title: Re: Testers wanted: FpDebug on Linux and Windows
Post by: Igor Kokarev on July 28, 2020, 01:34:56 pm
Martin,

I found a reason of the problem.

FpDebugger doesn't work on Windows 10 when Project Options use an option "Use external debug symbols file (-Xg)".

I see a warning, that FpDebugger doesn't work in this mode.

I prefer this option to reduce EXE file size. Of course, I perform strip command for a release version.
Title: Re: Testers wanted: FpDebug on Linux and Windows
Post by: Martin_fr on July 28, 2020, 02:25:42 pm
FpDebugger doesn't work on Windows 10 when Project Options use an option "Use external debug symbols file (-Xg)".

Ouch, my fault. I recently had to fix something on the gdb debugger. So my debugger was set to gdb.

Indeed, FpDebug does not yet support that.


It should not be too much work to implement. But I do not know when I will have time for it

It needs to be done in unit FpImgReaderWinPE (package FpDebug)

For the "how to" see unit LNfoDwarf (part of fpc), and exeinfo.
Code: Pascal  [Select][+][-]
  1. function OpenDwarf(addr : codepointer) : boolean;
  2.   if ReadDebugLink(e,dbgfn) then
  3.  
and the code in ReadDebugLink.

---
The warning prompt can be configured in
class function TFpDebugDebugger.RequiredCompilerOpts(ATargetCPU, ATargetOS: String): TDebugCompilerRequirements;
"dcrNoExternalDbgInfo"
Title: Re: Testers wanted: FpDebug on Linux and Windows
Post by: Igor Kokarev on July 28, 2020, 07:29:00 pm
Martin,

Thanks! It's not critical problem and it can wait.
Title: Re: Testers wanted: FpDebug on Linux and Windows
Post by: calebs on August 11, 2020, 09:45:31 pm
Hello all
i've followed all these steps and enabled fpdebugger but sometimes when i press f7 instead of f8 to enter a function or procedure it gives me protection fault.
Im using lazarus 2.0.10 rev 63526 x86 with windows 10x64 compiling in x86 mode (not x64).
Also, f7 doesn't get inside the code in control.inc for example when i press f7 on labeledit.caption:='hi'; (which is very anoying to me because i don't want to debug the master work of lazarus devs, only my mess lol) but i don't know if its normal.
When asked about debug info type  i've selected dwarf3-beta.
With dwarf2 also fails with f7 on some lines.

Is this normal because i'm not using trunk? thanks!


With my current gdb issues with console applications I finally decided to give fpdebug a try. And I must say I am extraordinarily surprised. It's almost like working with Delphi finally! Fly-over hints of properties? No problem (well, mostly...). 10 to 20 seconds waiting before the FileDialog opens in the debugger? No problem. I think i can do 90% of my debug work with it.

For those who like myself are confused by the many debugger packages available in the standard installation here are the steps that I took to make it work

- Go to "Package" > "Install/Uninstall packages". Make sure that LazDebuggerFp is installed (if not, install the package).
- Go to "Tools" > "Options" > "Debugger". In the gray combobox "Debugger type and paths" which usually displays "GNU debugger (gdb)", select "FpDebug standard Dwarf debugger (beta)".
- After compilation of a project you will be prompted to select which kind of dwarf debugging informations is too be used. The selection is written to the project file. (I hope permanent selection here is not a problem when the project is passed to others, like in my forum posts)

@Martin: There is also a package fpdebug. It is not installed on my systems. Is it needed?
Title: Re: Testers wanted: FpDebug on Linux and Windows
Post by: Martin_fr on August 11, 2020, 10:31:09 pm
First of all: Dwarf2 vs Dwarf3 etc only matters for inspecting variables.
Line info (for stepping) should be the same for all of them.

First question is, if you have debug info (dwarf) for the LCL / LCLBase?
Does "procedure TControl.SetText(const Value: TCaption);" have the blue dots.

It may work under gdb, because if "debug info type" is "default -g", that may (on 32bit win) generate stabs. And fpdebug does not read stabs.
The dialog that pops up, requiring dwarf, only affect project files.

You can
- edit the Package options. LclBase
- tools > configure build lazarus. Add  -gw   or -gw3 to options, and save (no need to rebuild the IDE, packages will be rebuild on next run)
- Use "additions and overrides"

With debug info, it works for me. 32 bit 2.0.10 IDE on a Win64 PC.


Stepping had a major overhaul in trunk. There was no known fix for anything matching the above. But if the issue is not due to missing line info, then there still is a chance that it works in trunk.

Title: Re: Testers wanted: FpDebug on Linux and Windows
Post by: calebs on September 02, 2020, 11:11:46 pm
i've encountered a problem with fpdebug and posted here

https://forum.lazarus.freepascal.org/index.php/topic,51310.0.html

i forgot to add i'm using windows 10x64 and lazarus 2.0.10 r63526 x86
Title: Re: Testers wanted: FpDebug on Linux and Windows
Post by: ccrause on December 04, 2020, 09:10:38 am
On Windows 10-64 and Lazarus 2.0.10 I noticed that debugging 32 bit applications from 32 bit Lazarus/fpdebug and 64 bit applications from 64 bit Lazarus/fpdebug works, but the cross bitness combinations fail.

When attempting to debug a 32 bit application with fpdebug (64 bit Lazarus) an error is displayed: "External exception 80000003".
When attempting to debug a 64 bit application with fpdebug (32 bit Lazarus) the executable fails to run and no error is displayed.

According to this Microsoft guide (https://docs.microsoft.com/en-us/windows/win32/winprog64/debugging-wow64) a debugger extension is required to debug 32 bit applications using a 64 bit debugger.  I'm not sure if other work-arounds exist, but this suggests that cross 32/64 bit debugging on Windows is more complicated than on Linux.

If this is true (I stopped poking around for Windows workarounds a long time ago), an information message to tell the user why debugging is not going to work seem appropriate.

Edit: I just noticed the following work-around for gdb (https://forum.lazarus.freepascal.org/index.php?topic=43774.0). I guess in principle if fpdebug is compiled as a stand-alone executable that matches the bitness of the target executable it should also work, although I prefer to have fpdebug compiled into Lazarus.
Title: Re: Testers wanted: FpDebug on Linux and Windows
Post by: Martin_fr on December 04, 2020, 12:53:19 pm
In trunk, a 64bit IDE can debug a 32bit target.

The other way round is not possible yet.
And indeed it gives no error, so that part should be reported on mantis.
Title: Re: Testers wanted: FpDebug on Linux and Windows
Post by: wp on December 04, 2020, 01:07:40 pm
As I wrote above I am an enthusiastic user of FPDebug now. There is one little annoyance, though: When I compile one of the Lazarus demos for example I am asked to switch to dwarf debug info. That's fine, but the problem is that this is now part of the project settings. When I commit this program back to svn (or git) the project settings are changed, and every subsequent user of this demo will have to use dwarf debug info. I think this should not happen. Is there a way to avoid changing the project settings when FPDebug is used, or to write the changed settings to the session file rather than to the lpi file?
Title: Re: Testers wanted: FpDebug on Linux and Windows
Post by: Martin_fr on December 04, 2020, 01:26:09 pm
Is there a way to avoid changing the project settings when FPDebug is used, or to write the changed settings to the session file rather than to the lpi file?

Afaik, debug info is stored in session.

I opened one of the examples to check, and
  Project options > Session
showed
  "Save in lpi file"

IMHO, that should be set to "save in lps" for all examples.
That would then need to be committed once to svn.

I prefer lps in project dir, but if you want clean svn checkouts, then it needs to be in config dir (which afaik can lead to name clashes)
Title: Re: Testers wanted: FpDebug on Linux and Windows
Post by: wp on December 04, 2020, 02:00:06 pm
Oh, you are right. I was mislead by what is shown in the IDE - I thought that the debugger settings are always taken from the lpi.

I think that none of the examples uses build modes. But what if there were a sample with a buildmode in which the box "In Session" is not checked?
Title: Re: Testers wanted: FpDebug on Linux and Windows
Post by: ccrause on December 04, 2020, 02:14:25 pm
In trunk, a 64bit IDE can debug a 32bit target.
I thought so. Unfortunately my employer supplied Windows machine has a policy that prevents copying anything containing "vlc", so getting FPC or Lazarus trunk sources on it is a major pain.  The only way I managed is to use an installer, which then skip the vlc packages on error.

Quote
And indeed it gives no error, so that part should be reported on mantis.
Issue 38167 (https://bugs.freepascal.org/view.php?id=38167)
Title: Re: Testers wanted: FpDebug on Linux and Windows
Post by: Martin_fr on December 04, 2020, 04:20:22 pm
and every subsequent user of this demo will have to use dwarf debug info.

Well, DWARF is the way better debug info. And for some targets FPC even does no longer has stabs.

In fact I had plans for a long time to change the IDE default. But that involves the Makefiles....
Title: Re: Testers wanted: FpDebug on Linux and Windows
Post by: wp on December 07, 2020, 07:07:14 pm
Is there a way to avoid changing the project settings when FPDebug is used, or to write the changed settings to the session file rather than to the lpi file?

Afaik, debug info is stored in session.

I opened one of the examples to check, and
  Project options > Session
showed
  "Save in lpi file"

IMHO, that should be set to "save in lps" for all examples.
That would then need to be committed once to svn.

I prefer lps in project dir, but if you want clean svn checkouts, then it needs to be in config dir (which afaik can lead to name clashes)

I've got to return to this topic... In the attachment there is a simple project which just does what I described above: it stores debug settings in the lpi file although "Project options" > "Session" shows "Save in lps file in current directory". This is a standard gui project with some controls and a stupid calculation created from default parameters. Since the debugger in my system is fpdebug I was forced to select one of the dwarf debug settings upon compilation. Looking into the lpi file I see that it contains this information. Martin, according to your response I would expect it to be in the lps file:

Code: XML  [Select][+][-]
  1.     <Linking>
  2.       <Debugging>
  3.         <DebugInfoType Value="dsDwarf2"/>
  4.       </Debugging>
  5.       <Options>
  6.         <Win32>
  7.           <GraphicApplication Value="True"/>
  8.         </Win32>
  9.       </Options>
  10.     </Linking>

Am I missing some setting to avoid this? And what is different in the Lazarus example projects?

I am using Laz trunk on Win10.
Title: Re: Testers wanted: FpDebug on Linux and Windows
Post by: Martin_fr on December 07, 2020, 08:37:42 pm
Please report it as bug then.  This pre-dates fpdebug.

I assumed it to always have been session.
Title: Re: Testers wanted: FpDebug on Linux and Windows
Post by: Sieben on December 07, 2020, 08:51:12 pm
Just yesterday I happened to notice that some of my packages contain this info as well in their .lpk-files. And that these settings obviously override the general setting for rebuilding IDE ('-gw3'). Packages that do not include explicit debug settings with their .lpk-file are listed with 'Automatic (-g)' in the IDE and also compile without info for fpdebug.

Edit: forgot to mention that fpdebug works great for me as well. I wouldn't go back to gdb even if these problems (https://forum.lazarus.freepascal.org/index.php/topic,35958.0.html) were solved.
TinyPortal © 2005-2018