Debugging no longer functioning

[TheMouseAUS]

A couple of weeks ago I got a new PC for work. I imaged my current one to the new and everything was fine. I had a kernel update (6.12) since and KDE Frameworks was updated to 6.9. Now debugging is broken. If I copy my project back to my older PC which was on KDE Frameworks 6.8 and kernel 6.11 (no project options changes) debug is fine. There were probably a few other libraries that updated too. Which ones should I be looking at for debugging to fully break? (Breakpoints dont work, unable to look at variables etc)

Lazarus 3.6
FPC 3.2.2
x86_64-linux-qt6

[Martin_fr]

Are you using gdb or fpdebug?
Menu: Tools > Options > Debugger Backend.


Do you see blue dots in the editors gutter, while the app is running?
Does it work, with a new application, just add a button + click, and "Caption := '123';"
?

[TheMouseAUS]

Sorry should of added that bit of info. Standard setup using fpdebug.

Debugging does not work anymore full stop, new projects or old projects and no blue dots. On my old PC all functions ok.

[TheMouseAUS]

I did try installing a newer version of libQt6Pas 6.2.8 -> 6.2.10, rebuilt everything (including the IDE) but that has not helped

[Martin_fr]

Can you look at the compiled exe? What size does it have? It should be a few MB at least. Otherwise it has no debug info, and you need to check the compile settings.

Please, also (for testing) make sure that you do not use "external debug info" (yes, it should work, but for testing...)

The "run" menu should have 2 entries "run" and "run without debugging". If the 2nd is actually "run with debugging" then your project options have disabled debugging.

In menu "Project > Project options" on the "compiler options > debugging" page, check that
- debug info is enabled
- debug info type is any of the "dwarf" settings.
(if you have custom options, make sure you do not use -gw4 / that only works with trunk/fixes compilers)


If all of the above is ok, then please run the IDE with

Code: Text  [Select][+][-]

1. ./lazarus --debug-log=LOG_FILE  --debug-enable=DBG_VERBOSE,DBG_WARNINGS,DBG_ERRORS,DBG_VERBOSE_BRKPOINT,DBG_STATE,DBG_EVENTS,DBG_BREAKPOINTS,DBG_FPDEBUG_VERBOSE,FPDBG_BREAKPOINT_ERRORS,FPDBG_BREAKPOINTS,FPDBG_COMMANDS,FPDBG_QUEUE

And after running your project in the debugger, attach the logfile.

[TheMouseAUS]

Interesting, compiling the project on both machines generates very difference size exe. I didnt notice till you mentioned the file size. The machine that debug does not work the exe is 30mb the one that does is 57mb! I have checked all the options and tried with the command line as suggested but no go.

[TheMouseAUS]

Log File as Requested

[Martin_fr]

It looks like missing debug info.

objdump --dwarf=decodedline  yourproject_executable

should be able to confirm that.
You either get no output (or no units/line-numbres). Or you get some, but none for your own units.

If that is so, then maybe it is an issue with the linker.
(the compiler is correctly called with -gw2)

To make sure there isn't any old compiler state, remove all *.o and *.ppu files from your project folder. And then compile again.

You might also try switching between "Dwarf 2" and "Dwarf 3" and see if it makes any difference. (I don't expect it will, but...)

[TheMouseAUS]

Thank you for helping me try to sort this. Yes you are right I get some debug info but not my own units. I created this as a new project so there were no *.o or *.ppu files to start with but I cleaned up recompiled but still the same result.

This is why I am wondering if an updated package has broken this function. I looked back at my update history, there has been only one update between the machines.

llvm is one such package 18.1.8 -> 19.1.6

[Martin_fr]

I don't know if llvm contains the linker - if indeed that is the issue.

If you compile your project then there should be .o and .ppu files somewhere in your project foldel (lib folder, or units/x86_64-linux/ or similar).  From the logfile /home/nathan/debug test/lib/x86_64-linux/

And they too, should change in size, if you switch debug info on and off.
So make sure they are big enough to contain debug info.


We know the linker can link some of the debug info (as it got it for some other units). So the question is why your units did not get correctly included.... (again, if the assumption is right to begin with).

My first idea is, that other units use dwarf3 and yours dwarf2 (or vice versa) and that maybe that caused an issue (it shouldn't, but ...).

If not that, then the next step will be to compile more verbose.

I don't currently recall how to get the linker more verbose. FPC has some option to pass arguments to the linker, and thus allow to make it more verbose.

But currently not sure which. Maybe someone else can help out...

[TheMouseAUS]

I see this in llvm change notes
"
    LLVM has switched from using debug intrinsics internally to using debug records by default. This should happen transparently when using the DIBuilder to construct debug variable information, but will require changes for any code that interacts with debug intrinsics directly. Debug intrinsics will only be supported on a best-effort basis from here onwards; for more information, see the migration docs.

    When emitting DWARF v2 and not in strict DWARF mode, LLVM will now add a DW_AT_type to instances of DW_TAG_enumeration_type. This is actually a DWARF v3 feature which tells tools what the enum’s underlying type is. Emitting this for v2 as well will help users who have to build binaries with DWARF v2 but are using tools that understand newer DWARF standards. Older tools will ignore it. (#98335)"

I tried to downgrade llvm version but it broke sddm for some reason

[TheMouseAUS]

OK I rolled back the last update and debugging is functioning again. One of those new packages is definitely what broke it. My guess - llvm?

[Martin_fr]

That is probably something someone with compiler background will be more likely to have an answer to.

Mind that llvm is more than just the linker (if indeed your system uses the linker from that package).

llvm is a compiler of its own. But that part should not affect you, because fpc does act as your compiler (unless you have a special build of fpc 3.3.1 which is configured to use llvm as backend / I doubt you have).

llvm also supplies the lldb debugger (though I don't know if your distro distributes that in the same package). However, you are using FpDebug, so lldb is not at all used (you can use lldb via the IDE, but there is usually no benefit).

The linker on Linux is typically called "ld". I don't know which libraries it does use. So not sure which packages affect that.

All that, if my guess is right, and it is linker related.
Mind, fpc also has bugs in the dwarf it generates. It is possible that a linker failed to read dwarf due to such a bug (some data type, or some specific bit of code). And then the info was skipped for that reason. In that case, maybe try fpc 3.2.3 or 3.3.1 (just to confirm) / and/or different dwarf versions.

I am not sure if objdump works on the *.o files. If it does, it might indicate if dwarf info is wrong. Though it may not be "wrong", but rather unexpected, in which case objdump may not give any mention...


Btw, what Linux distro?

[TheMouseAUS]

Hmm interesting binutils was updated also which provides 'ld' maybe that was the culprit. Will re apply the newest update and downgrade that package and see what happens.

I am using solus (plasma version) btw. Generally been an excellent distro overall.

[TheMouseAUS]

OK I updated the system and once again debugging was broken. Rolled back only the binutils package and success! Thank you so much for pointing me in the right direction :-) you are bang on llvm has nothing to do with it :-)