problem gdb13.1 with lazarus2.2.6 Raspberry5/Debian12

[spearman]

Hello,
Problem with Debuger GDB in IDE Lazarus.
Perhaps GDB13.1 no compatible with Lazarus2.2.6 ?
But i have also errors with fpdebug/Dwarf internal dwarf-debugger(don't starting process ).
i can't dowgrade gdb in version10 because others programs depends on it.
i can't upgrade Lazarus because Lazarus V2.2.6 is the stable version.
Thank you for your help.

====================
1)with GDB, at the 1st stopping point:

Code: Pascal  [Select][+][-]

1. GDB a rencontre une erreur interne:
2. Pendant l'exécution de la commande :
3. "TGDBMIDebuggerInstruction: "-data-evaluate-expression SELF^", [ifRequiresThread, ifRequiresStackFrame, ifRequiresMemLimit, ifRequiresArrayLimit] Thr=1 Frm=0"
4. GDB a signalé :
5. "&"A fatal error internal to GDB has been detected, further\ndebugging is not possible.  GDB will now terminate.\n\n"
6. &"This is a bug, please report it.""
7.  
8.  

With DWARF:

Code: Pascal  [Select][+][-]

1. "Error starting process"
2.  
3.  

Config:

Code: Pascal  [Select][+][-]

1. pi@pi51:~ $ lsb_release -a
2. No LSB modules are available.
3. Distributor ID: Debian
4. Description:    Debian GNU/Linux 12 (bookworm)
5. Release:        12
6. Codename:       bookworm
7. pi@pi51:~/dev/domsrvcliv16/domsrvlazv16 $ gdb -version
8. GNU gdb (Debian 13.1-3) 13.1
9.        
10. fpc est déjà la version la plus récente (3.2.2+dfsg-20).
11. lazarus-ide est déjà la version la plus récente (2.2.6+dfsg2-2).
12.  
13.  

[Martin_fr]

But i have also errors with fpdebug/Dwarf internal dwarf-debugger(don't starting process ).

FpDebug indeed does not work on Raspberry. FpDebug is i386/x86 only. Raspberry is arm.

So you have to use gdb.

Well there is a package for LLDB, but LLDB without FpDebug is alpha, so you not get any good of it / but if gdb does not work at all, then its better than nothing).
I don't think "LLDB + FpDebug" will work. That is only for Apple M1,M2,... -- Unless arm on Raspberry has the same registernames as M1. Then maybe...  (that is if you have a working lldb).

As for GDB.

Upgrading Lazarus will likely not help much. While GDB is still supported, that currently means: If there is time, then it will receive attention. And there simple had not been time.

One thing you can look at, is in Project settings.
When using gdb you should use "Dwarf with sets".

Do not use Dwarf-3. This has a way bigger likelihood of causing issues.

You may also get better results with FPC 3.2.3 (or 3.2.4 once that is released), as it has a few fixes in the Dwarf generator.

[Fred vS]

Hello.

Last gdb source/release > 10.0 have a feature to download all C dependencies debug files (their new default feature).
This feature is mainly for C programs and not really needed for fpc and using that new gdb with Lazarus will make problem because gdb is waiting for a command when asking if debug-infos should be downloaded.

There are no parameter for gdb to disable debuginfod, disable it is only possible when compiling gdb with --disable-debuginfod (sad but they dont want add one).

There are pre-compiled gdb with --disable-debuginfod ( but not yet for arm, so you will need to compile gdb from source with  --disable-debuginfod parameter ).
https://github.com/fredvs/gdb_nodebuginfod/releases

[Martin_fr]

Last gdb source/release > 10.0 have a feature to download all C dependencies debug files (their new default feature).
This feature is mainly for C programs and not really needed for fpc and using that new gdb with Lazarus will make problem because gdb is waiting for a command when asking if debug-infos should be downloaded.

I am not sure but I think that the IDE (not sure which version) deals with that....

Anyway his error is

Code: Pascal  [Select][+][-]

1. TGDBMIDebuggerInstruction: "-data-evaluate-expression SELF^"

Which happens when the debugger already runs.

And which is in my experience more likely with DWARF-3. But may or may not happen with older Dwarf too.


Btw, when changing DWARF settings => make sure any packages with debug info are also set to the same dwarf setting as the project.

And if your fpc / rtl is compiled with dwarf => it should match too.

[Fred vS]

I am not sure but I think that the IDE (not sure which version) deals with that....

Ooops, you are right, I just tested with Lazarus 3.6 and gdb 15.0 and indeed it deals it.
Sorry for the noise. 

[spearman]

But i have also errors with fpdebug/Dwarf internal dwarf-debugger(don't starting process ).

As for GDB.

Upgrading Lazarus will likely not help much. While GDB is still supported, that currently means: If there is time, then it will receive attention. And there simple had not been time.

One thing you can look at, is in Project settings.
When using gdb you should use "Dwarf with sets".

Do not use Dwarf-3. This has a way bigger likelihood of causing issues.

thanks for response.
i tried with GDB and option "Dwarf with sets" but same error.
Note that it's surprising that it works with gdb on the command line.
As you say that a Lazarus upgrade won't change anything, I'll try an FPC upgrade.

[Martin_fr]

For starters, on the command line, did you do

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

1. -data-evaluate-expression SELF^

or

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

1. -data-evaluate-expression SELF

Older versions of GDB did not handle the build in pointer.

But also some versions of GDB had problems only in certain sequences of commands. Most likely (I don't know the internals) they have a cache, and then maybe depending on that the succeed or fail.


Btw, the code you are debugging: is "self" a subclass of TObject?

Or are you inside an (advanced) record? or "type TFoo = object ... end"?


As I said: if you did build the RTL with dwarf-3 => then changing the project settings will not help. Even if you debug inside a project unit. Because the base TObject is declared in the RTL.

[spearman]

After testing, tforms created under an older Lazarus version (16RC2) are contributing to the problem.

The temporary solution is to recreate the forms with the current Lazarus version.
This greatly limits GDB crashes.

If you have any other ideas, I'm all ears.
Otherwise, I'll close this post.

Thanks again.

[Martin_fr]

Sorry no ideas right now.

Well you can try "stabs", but
- on many platforms fpc wont support it
- its old, outdated, and get you bare minimum debug info

With dwarf the problem are many fold.
- older fpc wrote incorrect dwarf / but that is afaik fixed in 3.2.3
- some gdb version made incorrect asserts, and crashed on valid dwarf (with an assert error)
- most gdb versions crash on some of the fpc generated dwarf (even if that dwarf is correct)

The last item is complex. Dwarf is very powerful, but that means the same debug info can be encoded in dozenz of ways. Gdb developers don't seem to test against fpc.

Additionally the IDE changes watches into expressions, that are (or were) needed (by older gdb) to get the correct result.
That means the debugger must do more processing, and has more chances to run into bugs (bugs in the debugger).

If nothing else works, maybe try the LLDB variant.

I don't know all the arm architectures. So I don't know if ASM wise the Apple M1 and your ARM CPU have the same registers. If they have then you could use the LLDB+FpDebug.
(If yes, that may be relatively stable / If not it may be possible to add that...)

Both LLDB variants are packages that must first be installed.

If you use the "LLDB alpha" (without fpdebug) you can step, and you can watch variables. But any expression would need to be C-style. So MyObj.FField would be MyObj->FField  (if it works at all / don't know).

[spearman]

Hello again,
False joy yesterday.
The problem remains.
Even if debug mode runs without crashing after recreating old Tforms, the crash appears the first time a variable is tracked.
I'll try your suggestions.

[Fred vS]

Hello again,
False joy yesterday.
The problem remains.
Even if debug mode runs without crashing after recreating old Tforms, the crash appears the first time a variable is tracked.
I'll try your suggestions.

Hum, if I may, did you try to use GDB compiled with --disable-debuginfod like proposed in my reply #2?
https://github.com/fredvs/gdb_nodebuginfod/releases

[Fred vS]

Oooops, sorry, I forgot that you use ARM32 Rpi and I did compile GDB only for x86_64.

[EDIT] If you want to compile GDB by yourself, it is easy, download source and in the source-directory:

Code: Pascal  [Select][+][-]

1. $ ../configure --disable-debuginfod --prefix=~/gdb-custom
2. $ make
3. $ make install

[Fred vS]

i can't dowgrade gdb in version10 because others programs depends on it.
i can't upgrade Lazarus because Lazarus V2.2.6 is the stable version.

OK, but if you use fpcupdeluxe, it will not touch to your current installation, all will be inside /home/you/fpcupdeluxe.
And you may choose old lazarus 2.2.6 if you want.

[spearman]

Hello,
I initially used fpc deluxe, but not knowing how to uninstall a version, I preferred "apt-get install...".
After installing fcp3.2.3+lazarus4.0 arm64.deb, the gdb errors are the same.
Regarding "-debuginfod," I haven't tested it yet, but I applied what I read in "https://wiki.lazarus.freepascal.org/GDB_Debugger_Tips#gdb.exe_has_stopped_working," i.e., the parameter "set DisableLoadSymbolsForLibraries=True." This once again improves things enormously.
Lazarus is usable again, even if there are some crashes depending on the variable (pointer, etc.) to be detailed (Ctrlf7).

[spearman]

Example:
Bug GDB with message "..ptype r.ftabmots..."
I think the problem appears depending on the type of variable being scanned (in this case, a dynamic array, etc.).
Perhaps another debugger option needs to be modified, but which one?
This is beyond my expertise.

Code: Pascal  [Select][+][-]

1.  
2. type Tarraystr      =array of string;                            
3. type rMotsExec=record
4.     FtabMots                  :Tarraystr;
5.     FValAvecParam             :boolean;
6.     FValTypeobjet             :typeobjet;//typeobjet int pour eviter appel unit domogenbase
7.     FValObjectcle             :tcle;
8.     FValObjectMot             :string;        //Mot reconnaissance parametre Objet
9.     FValObject                :Tobject;
10.     FValTfuncAutomateExec     :tfuncautomateExec;
11.     FValTfuncAutomateMENUExec :tfuncautomateMENUExec;
12.     end;