32bit debugging

[dbannon]

A bug only shows in the linux 32bit version of my app. So, I built a 32bit VM, install FPC and Laz Fixes 3.0 but I find the debugger will not step through LCL code (where the problem exists IMHO).

So, I went back to my Build VM, a 64bit one with appropriate cross compiler to 32bit. Again, trying to step through a 64bit binary, we skip over any LCL code. Step through my code, not LCL. But, exactly the same settings except a 64bit target, step through everything, just as I would expect. Seems to me, being a 32bit binary means no step through.

So, before I delve any deeper, thought I had better check, is it expected the debugger works with LCL code and a 32bit intel binary ? Why not ?

gtk2, normal debug settings, "Generate info for the debugger.." set but "Use external debug symbols file" NOT set.
OS : Debian 12; Ubuntu 20.04
Debuger : FpDebug internal Dwarf-debugger.
Debug data : Dwarf 2 with sets.

Davo

[Martin_fr]

Maybe the LCL is build with debug info type "stabs"? Project settings will not affect packages.

You can use package options, or in the project setting "addition and overrides" (see wiki).

[dbannon]

Hmm, Martin, I suspect its simpler than that, the i386 object files are not being built with any debug info

Code: [Select]

dbannon@u2004MnewBuild:~/bin/Lazarus/lazarus-fixes_3_0$ file ./lcl/units/i386-linux/gtk2/gtk2wscomctrls.o ./lcl/units/i386-linux/gtk2/gtk2wscomctrls.o: ELF 32-bit LSB relocatable, Intel 80386, version 1 (SYSV), not stripped
dbannon@u2004MnewBuild:~/bin/Lazarus/lazarus-fixes_3_0$ file ./lcl/units/x86_64-linux/gtk2/gtk2wscomctrls.o ./lcl/units/x86_64-linux/gtk2/gtk2wscomctrls.o: ELF 64-bit LSB relocatable, x86-64, version 1 (SYSV), with debug_info, not stripped

For clarity, just the right most end of the lines -

Code: [Select]

$> file ./lcl/units/i386-linux/gtk2/gtk2wscomctrls.o  ELF 32-bit LSB relocatable, Intel 80386, .. not stripped
$> file ./lcl/units/x86_64-linux/gtk2/gtk2wscomctrls.o ELF 64-bit LSB relocatable, x86-64, .., with debug_info, not stripped

Now, those i386 object files are being rebuilt if I do a clean up and rebuild for example but remain without debugging info (in the case of the 32bit build). Here is the project options debugging screen. I understand that should ensure all rebuilt files get debug info ?

Davo

[Martin_fr]

Hmm, Martin, I suspect its simpler than that, the i386 object files are not being built with any debug info

Well, same thing. Your project options only affect the files in your project:
project.lpr
unit1.pas

No file of any package is affected.
Exception "Additions and Overrides" can affect packages.

Or open the package (I think you need LclBase for those files), and go to Options (from the toolbar of the package window) and turn on debug info there.

Or go to menu Tools > Configure Build IDE
and add under custom: -gw3
(this should affect the base packages, but I don't know if it will auto rebuild them, or if you need to trigger via rebuild IDE)

[dbannon]

Hmm, yes, makes sense. But does seems strange that, out of the box, 64bit has LCL built with debugging info, 32bit does not .

I opened the lazarus.lpi project, it includes the gtk2 interface files as as a "Required Packages" (although I don't see the interfaces files as part of a package). That project did have debugging turned on, -gw3 was set, the gtk2 files were rebuilt with a "Clean up and Rebuild" but still without debugging. I am guessing that is because they are "Packages of the project"  in this context. Even though they do not present as part of a package ??

But I setting -gw3 in IDE rebuild options did the trick. But, in my mind, I don't see why that is necessary in a 32bit install but not necessary in a 64bit install.  In both cases, built from lazarus fixes 3.0 source. One gets debugging, the other does not.

Thanks Martin, your help greatly appreciated. I can get my debugging done now but suspect its much further upstream ....

Davo

[Martin_fr]

I am not involved in the Linux installer builds.

But on Windows for example there is a similar issue caused by different defaults that FPC has per target.

LCL is build wit -g
And for Win32 (fpc 3.2.2) that is still stabs => not useful.

[dbannon]

But on Windows for example there is a similar issue caused by different defaults that FPC has per target.

Yes, I guess that has to be the explanation. 32bit builds have been around for longer than the 64 so, perhaps, when someone added the 64bit ones, they took a more modern approach but no one is game enough to fiddle with the original. I might have a play when I get the time, at least document the differences.

Thanks,
Davo

[PascalDragon]

32bit builds have been around for longer than the 64 so, perhaps, when someone added the 64bit ones, they took a more modern approach but no one is game enough to fiddle with the original.

For 64-bit there simply was no choice, cause STABS does not support 64-bit.

[dbannon]

PascalDragon, are you sure the 32bit ones do have STABS information ?  The file command does not report any debugging information being present.

Davo

[Martin_fr]

PascalDragon, are you sure the 32bit ones do have STABS information ?  The file command does not report any debugging information being present.

Easy to check. Change the debugger to GDB. If GDB shows info for those files (other that the mangled symbols with lots of $$ in them), then info is present (GDB can read stabs and dwarf)

[dbannon]

Ah, OK, gdb installed, selected instead of the built in debugger. Stepping through the code, and it still does not step into (the 32bit) lcl code. So, I guess, no STABS.

Davo

[PascalDragon]

PascalDragon, are you sure the 32bit ones do have STABS information ?  The file command does not report any debugging information being present.

I didn't say anything about the debugging information included in the precompiled units (because there is none), but merely that when implementing the 64-bit targets there simply was no choice between STABS or DWARF, because STABS is simply not possible for 64-bit.