My plans are to revert FPC 3.2.2 to DWARF 2 (possibly also trying -godwarfsets and then -godwarfcpp) so that I can get back to a working Lazarus 2.2.4, test it, then to switch my day-to-day use to Lazarus 2.2.6+3.2.2.
I've identified a trivial bit of code in one of my projects where 2.2.4+3.2.2 using DWARF 2 barfs.
Using GDB. Build FPC 3.2.2 with -godwarfsets. Build Lazarus 2.2.4 with default options, app still barfs. Build Lazarus 2.2.4 with FPCOPT='gw2 -godwarfsets', app still barfs. Rather than relying on IDE default, build app with explicit selection of DWARF2 and then DWARF 2 with sets, app still barfs even after explicitly cleaning up the working directory.
Using FpDebug. FPC 3.2.2 built for DWARF 2 with -godwarfsets, Lazarus 2.2.4 built with FPCOPT='gw2 -godwarfsets'. App built for DWARF 2 (note: explicit setting rather than relying on default). Can progress past the point at which GDB barfed.
Revert FPC 3.2.2 to defaults (i.e. only -gl) since that's what everything else I've got here expects. Build Lazarus 2.2.4 with defaults. That's basically got 2.2.4+3.2.2 back to where I started, but (a) I'm now fairly confident that I can get better debugging from FpDebug than GDB, (b) I know that the FpDebug dialogue only means "tell the IDE to use some version of DWARF, don't rely on defaults", (c) we've collectively worked out how to use readelf to inspect the DWARF version of every unit hence (d) we can see fairly clearly where the IDE etc. is getting its understanding of the DWARF version to be used from the compiler.
Note that I'm not complaining now that I understand where we're at, but that initial "Set a DWARF version, stupid!" dialogue could possibly use readelf etc. to determine what version of DWARF was currently being defaulted to, so could be more like "You're already inheriting DWARF 2 from the compiler but I'd like it set explicitly please".
I might in practice add -godwarfsets to my FPC build once the dust has settled, but would appreciate anybody's experience on this.
All in all Kudos to Martin et al. for their hard work on FpDebug and related areas.
I'll report back separately on any further build issues with 2.2.4 (i.e. whether either of the DWARF 2 suboptions has an effect) and on the behaviour of gdb and FpDebug with DWARF 3.
I think the best way of summing that up is that without additional options 2.2.4 builds with an FPC compiled to generate DWARF 2, but not if FPC has been built to generate DWARF 3.
However since 2.2.6 is now current and builds correctly with both cases, further investigation of 2.2.4 is pointless other than insofar as it will help anybody getting here via Google etc. Hopefully, what I've condensed above is adequate to satisfy that requirement.
-----
Using my standard FPC 3.2.2 (i.e. compiled with -gl only implying DWARF 2) building Lazarus 2.2.6 with default options (i.e. inheriting DWARF 2) and using GDB gives me the same debugger problem as before. Rebuilding Lazarus with
FPCOPT='-gw3' doesn't change this since the program I'm debugging is non-GUI. Telling Lazarus to build the app using DWARF 3 results in a mix of v2 and v3 which still causes problems.
Building FPC 3.2.2 with explicit -gl -gw3 then using that to build Lazarus 2.2.6 fails as before, i.e. the DWARF 3 setting isn't propagating (which I think was seen earlier). Building Lazarus 2.2.6 with explicit
FPCOPT='-gw3' and trying to debug the same program crashes GDB as soon as it hits the breakpoint rather than at a subsequent "step into". I can confirm that all units are showing DWARF 3. Fortunately, FpDebug appears more robust.
I would not have been at all surprised if the version of GDB with Debian "Bookworm" (i.e. the recently-released "stable") had been robust with DWARF 3, i.e. it was basically a distro problem. Unfortunately this appears not to be the case, instead there's apparently something agley in Lazarus's handling of recent (e.g. v13.1) output compared with its handling of older (e.g. v10.1 from Debian "Bullseye").
MarkMLl
Recent
