GDB with Lazarus on Fedora 20

[alanphys]

I installed Fedora 20 on a new system recently and moved my development environment over to it. Everything went well until I attempted to debug one of my apps in Lazarus and got a number of error messages from the debugger (gdb).

A quick google (http://wiki.lazarus.freepascal.org/GDB_Debugger_Tips) told me there were issues with gdb ver >= 7.5.9. My version gdb 7.7.1. After several attempts to downgrade gdb using YUM I went to the gdb source (ftp://sourceware.org/pub/gdb/releases/) and downloaded the tarball for ver 7.5.1.

I extracted this to a local dir, compiled it and pointed the Lazarus Debugger path ("Tools,Options, Debugger") to the executable.

Amazingly it worked perfectly...until I logged in again the next morning when I got the same raft of debugger error messages as before.

I tried recompiling the debugger, I deleted the entire directory and extracted and compiled it again with no results. The Lazarus debugger path is definitely pointing to the downgraded version. I don't want to uninstall ver 7.7.1 as it wants to remove my entire development environment including Lazarus.

Why should the downgraded debugger work fine the first time and then never again? Does Lazarus perhaps have another path somewhere to the old debugger?

Any advice appreciated

[Martin_fr]

The path to the debugger is in Tools / Option / Debugger.


The problems where known with 5.9, 6.0 and 6.1. The 7.x has not yet been tested. It may, or may not have the issues.

You should attach the errors you get.

There are 2 ways an app can have debug info (stabs or dwarf). FPC does set he default, and I do not know what it is on Fedora.

Try both of them (dwarf is generally preferred).

You may need to rebuild the LCL (and other packages) with either no debug info, or the same type of debug info.

[alanphys]

Thanks for your help Martin, we are progressing. After recompiling the IDE I can now set a breakpoint. The debugger stops at the breakpoint and I can interrogate my variables. However if I try to step to the next line it crashes again. The log file is attached. I'm running:

Lazarus 1.2.2 (with option -g)
fpc 2.6.4
gdb 7.5.1
fedora 20 x64
Intel processor

I'll try downgrading further, but Lazarus 1.08 was running quite happily with gdb 7.5.1 on my previous 32 bit Fedora 18 system.

[Martin_fr]

Bit in a rush now. WIll look at it later.

But yes, it used 7.5.1 So that is ok.

Also it crashes at the end of the single step. This is a new one. Most gdb clashes are when you inspect variables...

I the mean time, try the no-solib setting
http://wiki.lazarus.freepascal.org/GDB_Debugger_Tips#gdb.exe_has_stopped_working

---
Also:

if you do not step into LCL, then add -g- to the options in configure build lazarus. ANd rebuild again.

Check the setup
- NO optimizations -O- or -O1 are the only allowed
- NO smart linking

[Martin_fr]

Do you use include files? Or inlining?
----------
I looked up the error line in gdb sources.

It refers to stabs. So best to try to remove all stabs symbols from your app. Unfortunately LCL and other packages may default to them.

You can try to set either -g- in options in configure build lazarus. Or -gw

Or even more powerful set one of them in "Overrides and Additions" (Project Opts)

And of course set your own apps options to dwarf (Proj Opts / Debugging)

[alanphys]

Thanks for your help Martin. Setting -g in the options and rebuilding the IDE and then putting -gw in the project overrides and additions seems to have done the trick.

Does setting -gw in the overrides and additions override the IDE settings, or just the local project?

Cheers

[Martin_fr]

Setting -g in the options and rebuilding the IDE

Actually -g is (on most systems) equal to -gs
I wrote -g- (trailing -)

But it does not matter "Override and Additions" take care of it.

Does setting -gw in the overrides and additions override the IDE settings, or just the local project?

http://wiki.lazarus.freepascal.org/IDE_Window:_Compiler_Options#Additions_and_Overrides

It affects the project.
HOWEVER:
- it rebuilds all packages by the project (unless you specify "Tagets")
  This is in that case what you need. A single package not on -gw (Actually -g- would be fine / but one package on -g or -gs and your gdb crashes)
  If you build another project it will again build all of them. (exception see below)

So it takes longer, if you switch projects and build.
- You can also set the global ide conf to -gw
- you can change the output dir for packages so they do not replace the default build (Yet the default build does not work for you)

HOWEVER (part 2) [and above mentioned exception]
- if you add the build mode under "Stored in IDE" and tick the build-mode "default"
  then it is set for all projects (except projects on a different build-mode.

I actually recommend to do that.

Then add a release build mode to your projects,  (If you use the automatic creation of "debug and release mode" then also tick the "debug" mode afterwards.

The release mode stays unticked, and will not be affected.

[BigChimp]

Actually -g is (on most systems) equal to -gs

Sorry to bother you but I always though -g on Linux and Windows equals dwarf, not stabs? Just checked with readelf --all exe | grep -i dwarf on x64 linux fpc trunk and I get some hits (none when searching on stabs)?

Thanks.

[Martin_fr]

make sure you have no units that use debug info.

use objdump, it will give you detailed info.

you can grep for .debug_info (dwarf) but not sure if there is anything for stabs.

[BigChimp]

Hmmm, objdump gives info on both stabs and dwarf.

Have tested on Windows => -g indeed seems to be stabs; changed to -gw2 and got dwarf info. Looking forward to much smoother debugging although my desk is now damaged from my head hitting it repeatedly

Thanks, Martin!

[Martin_fr]

although my desk is now damaged from my head hitting it repeatedly

I recommend the wall. Easier to repair Occasionally fill some plaster into the cracks, and slap some paint on. personal experience

[BigChimp]

Good idea