Moving away from GDB
lazarus / 12-Debugger

----------------------------------------------------------------------
MarkMLl · 2023-08-31 08:50

For the last 15 years or so, I have habitually compiled both FPC and
Lazarus from source on various platforms rather than using prebuilt
packages.

On Debian Linux "Bookworm" x86_64, Lazarus 2.2.4 is clearly struggling
with GDB: the debugger regularly crashes particularly if hovering over
any variable other than a simple scalar.

With reference to https://wiki.freepascal.org/Debugger_Setup#Setting_u
p_the_debugger_backend_for_the_IDE , Tools -> Options -> Debugger
Backend only shows "GNU Debugger (gdb)" in the drop-down at the top of
the window. I can see that the "LazDebuggerFP 1.0" package is
installed.

What do I do to enable the new-style debugger?

MarkMLl

p.s. I would far prefer, this time round, to not be told that I'm the
one at fault for running an experimental OS or that a mere user should
not be attempting to build the IDE from source.

----------------------------------------------------------------------
Martin_fr · 2023-08-31 09:00

GDB works best with "DWARF 2 with sets" ... but even then.  DWARF 3 is
a gdb killer. (And that includes mixed compiles, e.g. fpc/rtl has
dwarf 3 and your project has dwarf 2.

As for setting up:
https://wiki.lazarus.freepascal.org/Debugger_Setup

A new install should already have FpDebug in the list. If you upgrade
to 3.0 then you should be asked at startup.
Also running
   lazarus --setup
brings up the start dialog, that has options to change the settings.


Otherwise:
- Button "Add"
- Select "FpDebug" as type
- press ok

---
You can also set a debugger per project in the project options....

----------------------------------------------------------------------
MarkMLl · 2023-08-31 10:07

Thanks Martin, I'll give that some thought. However initially:

Quote from: Martin_fr on August 31, 2023, 11:00:50 amGDB works best
with "DWARF 2 with sets" ... but even then.  DWARF 3 is a gdb killer.
(And that includes mixed compiles, e.g. fpc/rtl has dwarf 3 and your
project has dwarf 2.

The IDE appears to be using automatic selection of debug type, which I
suspect is inherited from when the configuration file was first set up
(which is quite possibly several versions ago). FPC (i.e. RTL etc.)
was compiled with -O- -gl -Xs- -vt The file command confirms that
binaries are unstripped, but doesn't say much else.

Since this could possibly help others, how can I inspect a binary and
determine what DWARF variant is in use?

Project options only give GDB as an option. I've not explored your
other suggestions yet since I think it's important to first determine
DWARF properties.

MarkMLl

----------------------------------------------------------------------
Martin_fr · 2023-08-31 10:20

"automatic" is decided by FPC. Afaik it's preset for each target. (so
it does not depend what was used to build the compiler/rtl).
Afaik, on all major platforms it is some version of DWARF (i.e. stabs,
is no longer used on major platforms).

objdump should probably give you insight (I would have to check what
the quickest way is). "objdump --dwarf=info" => very very long output.
Mixed within a header for each unit, that should have a version.


But to know if you use DWARF 3 or higher: Are your local vars shown
all uppercase?
"All upper" = DWARF 2
"mixed case" = DWARF 3 or higher.

So of course you can still have some units that and other units
this... But then you need to run the long objdump.


fpc also introduced
 -godwarfcpp
https://www.freepascal.org/docs-html/user/userap1.html

But I have not tested it much.

----------------------------------------------------------------------
rvk · 2023-08-31 10:46

Quote from: MarkMLl on August 31, 2023, 12:07:37 pmSince this could
possibly help others, how can I inspect a binary and determine what
DWARF variant is in use?
Would this work?
readelf --debug-dump=info binary_name | head | grep -A 2 'Compilation
Unit @'

And this for all included units?
readelf --debug-dump=info mytest | grep -A 2 'Compilation Unit @'

----------------------------------------------------------------------
MarkMLl · 2023-08-31 11:51

Quote from: rvk on August 31, 2023, 12:46:32 pmQuote from: MarkMLl on
August 31, 2023, 12:07:37 pmSince this could possibly help others, how
can I inspect a binary and determine what DWARF variant is in use?
Would this work?
readelf --debug-dump=info binary_name | head | grep -A 2 'Compilation
Unit @'

And this for all included units?
readelf --debug-dump=info mytest | grep -A 2 'Compilation Unit @'

Since that's an easy one to check,

Code: Text  [Select][+][-]window.onload = function(){var x1 =
document.getElementById("main_content_section"); if (x1) { var x =
document.getElementsByClassName("geshi");for (var i = 0; i
bin.fpc/3.2.2$ readelf --debug-dump=info fp | head | grep -A 2
'Compilation Unit @'  Compilation Unit @ offset 0:   Length:      
 0x234a (32-bit)   Version:       2bin.fpc/3.2.2$ readelf --debug-
dump=info fpc | head | grep -A 2 'Compilation Unit @'  Compilation
Unit @ offset 0:   Length:        0x234a (32-bit)   Version:      
2bin.fpc/3.2.2$ file fpfp: ELF 64-bit LSB executable, x86-64, version
1 (SYSV), statically linked, for GNU/Linux 2.4.0, with debug_info, not
strippedbin.fpc/3.2.2$ file fpcfpc: ELF 64-bit LSB executable, x86-64,
version 1 (SYSV), statically linked, for GNU/Linux 2.4.0, with
debug_info, not stripped share.lazarus/lazarus-stable$ readelf
--debug-dump=info lazarus | head | grep -A 2 'Compilation Unit @' 
Compilation Unit @ offset 0:   Length:        0x2362 (32-bit) 
 Version:       2share.lazarus/lazarus-stable$ file lazaruslazarus:
ELF 64-bit LSB executable, x86-64, version 1 (SYSV), dynamically
linked, interpreter /lib64/ld-linux-x86-64.so.2, for GNU/Linux 2.4.0,
with debug_info, not stripped 
I'll try to look at some of the other suggestions later.

MarkMLl

----------------------------------------------------------------------
Martin_fr · 2023-08-31 12:05

I'm not familiar with "readelf", but it looks like it gets the same
data. So that would be "Dwarf 2" (with/without sets can't be told, but
probably makes no difference).

The grep would also show you each and every unit ("compilation unit")

----------------------------------------------------------------------
MarkMLl · 2023-08-31 12:22

Quote from: Martin_fr on August 31, 2023, 12:20:02 pmBut to know if
you use DWARF 3 or higher: Are your local vars shown all uppercase?
"All upper" = DWARF 2
"mixed case" = DWARF 3 or higher.

The IDE's "Local Variables" debugging window shows locally-declared
variables in upper-case, plus a symbol representing what I presume is
the starting value in mixed case i.e.

Code: Pascal  [Select][+][-]window.onload = function(){var x1 =
document.getElementById("main_content_section"); if (x1) { var x =
document.getElementsByClassName("geshi");for (var i = 0; i var 
tempExts: TExtractions= nil; 
results in TEMPEXTS and defaulttempExts both with value zero. Hence I
presume we're talking about DWARF 2.

The "Add" button at the top of the window has allowed me to add
FpDebug, and also automatically selected it. I've not yet been able to
put any time into exercising it: I'll report back when I can.

Losing gdb presumably means that it's no longer to use gdbserver.

MarkMLl

----------------------------------------------------------------------
Martin_fr · 2023-08-31 12:43

Quote from: MarkMLl on August 31, 2023, 02:22:25 pmThe IDE's "Local
Variables" debugging window shows locally-declared variables in upper-
case, plus a symbol representing what I presume is the starting value
in mixed case i.e.

Code: Pascal  [Select][+][-]window.onload = function(){var x1 =
document.getElementById("main_content_section"); if (x1) { var x =
document.getElementsByClassName("geshi");for (var i = 0; i var 
tempExts: TExtractions= nil; 
results in TEMPEXTS and defaulttempExts both with value zero. Hence I
presume we're talking about DWARF 2.
Yes, also shown by the readelf.

There are some symbols that FPC may add (in mixed case, like the
current function name as alias for "RESULT". Or some symbols with  "$"
in it (like "$parentfp". (the exact name varies by fpc version).

With fpdebug, I suggest to switch to Dwarf 3.

QuoteThe "Add" button at the top of the window has allowed me to add
FpDebug, and also automatically selected it. I've not yet been able to
put any time into exercising it: I'll report back when I can.

Losing gdb presumably means that it's no longer to use gdbserver.

Unfortunately. But if it is in the list of configured debuggers, you
can select it in project settings. You then just have to be careful of
certain values. (You can test the -godwarfcpp / but I don't know any
details on it / don't use it with fpdebug)

For AVR, there is a fpdebug package that afaik uses gdbserver.
(package comes with IDE, but must be installed).

Not gdb server, but if you have issuse, there is a mix of gdb +
fpdebug (LazDebuggerFpGdbmi) => runs in gdb, but evals watches via
fpdebug (needs local exe for symbols).
This is useful if you debug a lot in the kernel / 3rd party libs =>
gdb is still better at unrolling the stack in those cases.

In theory that could be extended to gdbserver. But no plans for that
at the moment.
Also: It's considerable slower.

----------------------------------------------------------------------
MarkMLl · 2023-08-31 13:03

Ooh, this is interesting :-)

I had a couple of minutes to knock together so started the IDE and
went to set a breakpoint. The IDE responded with a dialogue

"Enable Dwarf 2 (-gw)?"

"The project does not write debug info in Dwarf format. The "FpDebug
internal Dwarf-debugger" supports only Dwarf."

With buttons for Dwarf 2, Dwarf 3 and Dwarf 2 with sets with the last
of those default.

I've not changed anything yet since I think that reviewing what I've
actually got in the RTL and app being compiled (which the IDE clearly
doesn't think is Dwarf 2) might be useful.

My notes from earlier in the thread show -O- -gl -Xs- -vt being used
for the compiler/RTL, and inspecting the command line that the IDE
intends to use suggest that it's propagating the compiler's -gl
option.

Reviewing fpc -h output, it looks as though gdb is happy if a binary
is compiled with -gl but FpDebug requires -gl -gw or even something
more specific. I think it would be extremely useful if the compiler
could say "you've got this" as well as "you need that".

For info, Bookworm's gdb --version says 13.1

MarkMLl

----------------------------------------------------------------------
Martin_fr · 2023-08-31 13:38

-gl  => the l is line info, i.e. includes the unit for dumping traces
with resolved addresses as unit/line.

-g  is debug info in either stabs or dwarf. Nowadays this is 99.9%
dwarf. But only fpc knows what it is going to use (depending on your
target). Since the IDE does not know, it can not relay on it.

GDB accepts stabs or dwarf.
FpDebug accepts only dwarf.

Both gdb and fpdebug "support" dwarf 2 and 3.
In fpdebug dwarf 3 gives the better results.
In gdb there are issues (either issues of gdb, or how fpc writes dwarf
3...)

Hence, if using gdb, stick to dwarf 2 (though in your case, even that
did not help / feel free to test dwarf 3, maybe you have a good
version of gdb).

----------------------------------------------------------------------
MarkMLl · 2023-09-01 07:31

For the purpose of my desktop system running Debian "Bookworm":

I'm obliged to use a very recent FPC on account of linker changes,
which I think at the moment means 3.2.2. It looks as though a new
version of gdb is causing Lazarus problems /possibly/ because I'm
still using DWARF 2: if this is the case it might be reasonable to
assume that the binutils developers are now oriented towards DWARF 3
(and might even be testing it properly).

I suspect I started using -gl /very/ early on when I needed backtraces
to help the developers. Investigating various combinations using a
"cogito ergo sum" program (i.e. begin-end only) and looking at the
checksum and size of the resulting binary:

Code: Text  [Select][+][-]window.onload = function(){var x1 =
document.getElementById("main_content_section"); if (x1) { var x =
document.getElementsByClassName("geshi");for (var i = 0; i 1867881469
231872  dummy_3331781544 1078504 dummy_gl3331781544 1078504
dummy_gl_gw3331781544 1078504 dummy_gl_gw20375397870 1078504
dummy_gl_gw34291773809 1021680 dummy_gw23297076883 1021680 dummy_gw3 
i.e. -gl implies -gw2 (but not vice-versa), and switching to -gw3
changes the checksum (as expected) but not the size of the binary
(which is suspicious).

I'm going to recompile FPC 3.2.2 (i.e. including the RTL etc.) for
DWARF 3 and use that to rebuild Lazarus 2.2.4. I'll report back on the
stability of gdb and FpDebug.

Booting a 32-bit laptop and looking at old versions of the compiler,
it looks as though -gw3 was supported as far back as 2.2.2. Allowing
that I've got FPC 2.2.4 and Lazarus 0.9.24 paired together and
assuming that FPC was actually generating debugging records properly,
the limiting factor would appear to be the distro's binutils version.

MarkMLl

----------------------------------------------------------------------
MarkMLl · 2023-09-01 13:14

Looking at this in a bit more detail for a few minutes. The first
thing I'd say is that the dwarfdump program is supposed to be able to
extract the format and version from a binary, but I've had no success
with it, hence am sticking with rvk's suggested

Code: Text  [Select][+][-]window.onload = function(){var x1 =
document.getElementById("main_content_section"); if (x1) { var x =
document.getElementsByClassName("geshi");for (var i = 0; i $ readelf
--debug-dump=info dummy_ | head | grep -A 2 'Compilation Unit @' 
which, now that I've got a better idea what I'm looking for, I see in
various other discussions.

Using this test script:

Code: Text  [Select][+][-]window.onload = function(){var x1 =
document.getElementById("main_content_section"); if (x1) { var x =
document.getElementsByClassName("geshi");for (var i = 0; i
#!/bin/sh echo 'FPC compiler/runtimes built with -gl only.' echo 'fpc
-odummy_ dummy.pas'fpc -odummy_ dummy.pas > /dev/nullreadelf --debug-
dump=info dummy_ | head | grep -A 2 'Compilation Unit @' echo 'fpc -gl
-odummy_gl dummy.pas'fpc -gl -odummy_gl dummy.pas > /dev/nullreadelf
--debug-dump=info dummy_gl | head | grep -A 2 'Compilation Unit
@' echo 'fpc -gl -gw2 -odummy_gl_gw2 dummy.pas'fpc -gl -gw2
-odummy_gl_gw2 dummy.pas > /dev/nullreadelf --debug-dump=info
dummy_gl_gw2 | head | grep -A 2 'Compilation Unit @' echo 'fpc -gl
-gw3 -odummy_gl_gw3 dummy.pas'fpc -gl -gw3 -odummy_gl_gw3 dummy.pas >
/dev/nullreadelf --debug-dump=info dummy_gl_gw3 | head | grep -A 2
'Compilation Unit @' echo 'fpc -gw2 -odummy_gw2 dummy.pas'fpc -gw2
-odummy_gw2 dummy.pas > /dev/nullreadelf --debug-dump=info dummy_gw2 |
head | grep -A 2 'Compilation Unit @' echo 'fpc -gw3 -odummy_gw3
dummy.pas'fpc -gw3 -odummy_gw3 dummy.pas > /dev/nullreadelf --debug-
dump=info dummy_gw3 | head | grep -A 2 'Compilation Unit @' cksum
dummy_* | sortrm dummy_* 
and starting off with a version of the compiler etc. built with -gl
only, the script produces this output:

Code: Text  [Select][+][-]window.onload = function(){var x1 =
document.getElementById("main_content_section"); if (x1) { var x =
document.getElementsByClassName("geshi");for (var i = 0; i FPC
compiler/runtimes built with -gl only.fpc -odummy_ dummy.pasfpc -gl
-odummy_gl dummy.pas  Compilation Unit @ offset 0:   Length:      
 0x234a (32-bit)   Version:       2fpc -gl -gw2 -odummy_gl_gw2
dummy.pas  Compilation Unit @ offset 0:   Length:        0x234a
(32-bit)   Version:       2fpc -gl -gw3 -odummy_gl_gw3 dummy.pas 
Compilation Unit @ offset 0:   Length:        0x234a (32-bit) 
 Version:       2fpc -gw2 -odummy_gw2 dummy.pas  Compilation Unit @
offset 0:   Length:        0x234a (32-bit)   Version:       2fpc -gw3
-odummy_gw3 dummy.pas  Compilation Unit @ offset 0:   Length:      
 0x234a (32-bit)   Version:       21798613560 1078504
dummy_gl1798613560 1078504 dummy_gl_gw22745444480 1078504
dummy_gl_gw32927890045  231872 dummy_3549871481 1021680
dummy_gw23765698736 1021680 dummy_gw3 
If instead I use a compiler built with -gl -gw2:

Code: [Select]FPC compiler/runtimes built with -gl -gw2.
fpc -odummy_ dummy.pas
fpc -gl -odummy_gl dummy.pas
  Compilation Unit @ offset 0:
   Length:        0x234a (32-bit)
   Version:       2
fpc -gl -gw2 -odummy_gl_gw2 dummy.pas
  Compilation Unit @ offset 0:
   Length:        0x234a (32-bit)
   Version:       2
fpc -gl -gw3 -odummy_gl_gw3 dummy.pas
  Compilation Unit @ offset 0:
   Length:        0x234a (32-bit)
   Version:       2
fpc -gw2 -odummy_gw2 dummy.pas
  Compilation Unit @ offset 0:
   Length:        0x234a (32-bit)
   Version:       2
fpc -gw3 -odummy_gw3 dummy.pas
  Compilation Unit @ offset 0:
   Length:        0x234a (32-bit)
   Version:       2
1798613560 1078504 dummy_gl
1798613560 1078504 dummy_gl_gw2
2745444480 1078504 dummy_gl_gw3
2927890045  231872 dummy_
3549871481 1021680 dummy_gw2
3765698736 1021680 dummy_gw3

The good news here is that the checksums suggest that the build is
reproducible. The bad news is that compiling the test program with
-gw3 still produces a binary with DWARF 2 debug info, if the readelf
output is to be believed.

If instead I use a compiler built with -gl -gw3:

Code: Text  [Select][+][-]window.onload = function(){var x1 =
document.getElementById("main_content_section"); if (x1) { var x =
document.getElementsByClassName("geshi");for (var i = 0; i FPC
compiler/runtimes built with -gl -gw3.fpc -odummy_ dummy.pasfpc -gl
-odummy_gl dummy.pas  Compilation Unit @ offset 0:   Length:      
 0x1eda (32-bit)   Version:       3fpc -gl -gw2 -odummy_gl_gw2
dummy.pas  Compilation Unit @ offset 0:   Length:        0x1eda
(32-bit)   Version:       3fpc -gl -gw3 -odummy_gl_gw3 dummy.pas 
Compilation Unit @ offset 0:   Length:        0x1eda (32-bit) 
 Version:       3fpc -gw2 -odummy_gw2 dummy.pas  Compilation Unit @
offset 0:   Length:        0x1eda (32-bit)   Version:       3fpc -gw3
-odummy_gw3 dummy.pas  Compilation Unit @ offset 0:   Length:      
 0x1eda (32-bit)   Version:       31358981819 1029376
dummy_gl1358981819 1029376 dummy_gl_gw21605665511  975368
dummy_gw31860338280 1029376 dummy_gl_gw31874535790  975368
dummy_gw22927890045  231872 dummy_ 
So we can say definitely (from the checksums) that -gl still implies
-gw2, however from the readelf output I'm not sure what is /really/
being put into the binary file.

I've put minimal time into working with the IDE yet, since I think
that this takes us back to the issue when FpDebug unexpectedly
prompted me for a DWARF version: we need some reliable way of working
out that's actually in there.

MarkMLl

----------------------------------------------------------------------
rvk · 2023-09-01 13:35

Weird. You script outputs this for me:

Quotefpc -odummy_ dummy.pas
fpc -gl -odummy_gl dummy.pas
  Compilation Unit @ offset 0x0:
   Length:        0x77 (32-bit)
   Version:       2
fpc -gl -gw2 -odummy_gl_gw2 dummy.pas
  Compilation Unit @ offset 0x0:
   Length:        0x77 (32-bit)
   Version:       2
fpc -gl -gw3 -odummy_gl_gw3 dummy.pas
  Compilation Unit @ offset 0x0:
   Length:        0x78 (32-bit)
   Version:       3
fpc -gw2 -odummy_gw2 dummy.pas
  Compilation Unit @ offset 0x0:
   Length:        0x77 (32-bit)
   Version:       2
fpc -gw3 -odummy_gw3 dummy.pas
  Compilation Unit @ offset 0x0:
   Length:        0x78 (32-bit)
   Version:       3
116035507 226696 dummy_
2093630322 1076400 dummy_gw2
2856255440 1139768 dummy_gl
2856255440 1139768 dummy_gl_gw2
3552731905 1139768 dummy_gl_gw3
3883557931 1076400 dummy_gw3
Checking my compiled fpc I get this:
Quote# readelf --debug-dump=info ~/dev/fpc/bin/fpc | head | grep -A 2
'Compilation Unit @'
  Compilation Unit @ offset 0x0:
   Length:        0xfad (32-bit)
   Version:       2
It looks like the gwx switch doesn't work for you and it always takes
the same as the one compiled with fpc

----------------------------------------------------------------------
marcov · 2023-09-01 13:49

Probably the order is important with -gl triggering dwarf2, overriding
an earlier -gw3

Note that combinations are also possible, it would be interesting to
see what -gw3l  and -glw3 resp. do

----------------------------------------------------------------------
rvk · 2023-09-01 14:01

Quote from: marcov on September 01, 2023, 03:49:33 pmProbably the
order is important with -gl triggering dwarf2, overriding an earlier
-gw3

Note that combinations are also possible, it would be interesting to
see what -gw3l  and -glw3 resp. do
Nope, not for me. If I put the -gl after the -gw3 I still get DARF 3.

Quotefpc -odummy_ dummy.pas
fpc -gl -odummy_gl dummy.pas
  Compilation Unit @ offset 0x0:
   Length:        0x77 (32-bit)
   Version:       2
fpc -gw2 -gl -odummy_gl_gw2 dummy.pas
  Compilation Unit @ offset 0x0:
   Length:        0x77 (32-bit)
   Version:       2
fpc -gw3 -gl -odummy_gl_gw3 dummy.pas
  Compilation Unit @ offset 0x0:
   Length:        0x78 (32-bit)
   Version:       3
fpc -gw2 -odummy_gw2 dummy.pas
  Compilation Unit @ offset 0x0:
   Length:        0x77 (32-bit)
   Version:       2
fpc -gw3 -odummy_gw3 dummy.pas
  Compilation Unit @ offset 0x0:
   Length:        0x78 (32-bit)
   Version:       3
116035507 226696 dummy_
2093630322 1076400 dummy_gw2
2856255440 1139768 dummy_gl
2856255440 1139768 dummy_gl_gw2
3552731905 1139768 dummy_gl_gw3
3883557931 1076400 dummy_gw3
And the combination -gw3 with -gl
Quotefpc -glw3 -odummy_glw3 dummy.pas
  Compilation Unit @ offset 0x0:
   Length:        0x78 (32-bit)
   Version:       3
fpc -gw3l -odummy_gw3l dummy.pas
  Compilation Unit @ offset 0x0:
   Length:        0x78 (32-bit)
   Version:       3
3552731905 1139768 dummy_glw3
3552731905 1139768 dummy_gw3l
PS. I did this on arm64. I will try on amd64 (but the download of my
bootstrap is very slow at the moment. WiFi grrr).

----------------------------------------------------------------------
rvk · 2023-09-01 14:21

Result on my newly installed Debian x86_64 (amd64).

This is indeed different from the arm64 result.

Quotefpc -odummy_ dummy.pas
fpc -gl -odummy_gl dummy.pas
  Compilation Unit @ offset 0:
   Length:        0x2611 (32-bit)
   Version:       3
fpc -gw2 -gl -odummy_gl_gw2 dummy.pas
  Compilation Unit @ offset 0:
   Length:        0x2611 (32-bit)
   Version:       3
fpc -gw3 -gl -odummy_gl_gw3 dummy.pas
  Compilation Unit @ offset 0:
   Length:        0x2611 (32-bit)
   Version:       3
fpc -gw2 -odummy_gw2 dummy.pas
  Compilation Unit @ offset 0:
   Length:        0x2611 (32-bit)
   Version:       3
fpc -gw3 -odummy_gw3 dummy.pas
  Compilation Unit @ offset 0:
   Length:        0x2611 (32-bit)
   Version:       3
1036446534 1035608 dummy_gw2
152834824 1089568 dummy_gl_gw2
222374223 1035616 dummy_gw3
4248296208 1089568 dummy_gl
4248296208 1089568 dummy_gl_gw3
4276196424 206736 dummy_
My fpc itself, compiled with the same script, is now also DWARF 3 
(my script options are -g -gl -O2 -Xs -CX -XX -v0 and it seems to
compile version 3 ??)

Code: Pascal  [Select][+][-]window.onload = function(){var x1 =
document.getElementById("main_content_section"); if (x1) { var x =
document.getElementsByClassName("geshi");for (var i = 0; i $ readelf
--debug-dump=info ~/dev/fpc/bin/fpc | head | grep -A 2 'Compilation
Unit @'  Compilation Unit @ offset 0:   Length:        0x2611
(32-bit)   Version:       3
I'll update my arm version to see if the result changes.

----------------------------------------------------------------------
rvk · 2023-09-01 14:49

With a freshly compiled version of fpc trunk on arm64.
(so definitely something different with amd64)

This seems correct:

Quotefpc -odummy_ dummy.pas
fpc -gl -odummy_gl dummy.pas
  Compilation Unit @ offset 0x0:
   Length:        0x77 (32-bit)
   Version:       2
fpc -gw2 -gl -odummy_gl_gw2 dummy.pas
  Compilation Unit @ offset 0x0:
   Length:        0x77 (32-bit)
   Version:       2
fpc -gw3 -gl -odummy_gl_gw3 dummy.pas
  Compilation Unit @ offset 0x0:
   Length:        0x78 (32-bit)
   Version:       3
fpc -gw2 -odummy_gw2 dummy.pas
  Compilation Unit @ offset 0x0:
   Length:        0x77 (32-bit)
   Version:       2
fpc -gw3 -odummy_gw3 dummy.pas
  Compilation Unit @ offset 0x0:
   Length:        0x78 (32-bit)
   Version:       3
1102420958 1059136 dummy_gw2
1311066681 1118416 dummy_gl
1311066681 1118416 dummy_gl_gw2
244809924 1118416 dummy_gl_gw3
2735510098 1059136 dummy_gw3
3887319730 226696 dummy_
Code: Bash  [Select][+][-]window.onload = function(){var x1 =
document.getElementById("main_content_section"); if (x1) { var x =
document.getElementsByClassName("geshi");for (var i = 0; i $ readelf
--debug-dump=info ~/dev/fpc/bin/fpc | head | grep -A 2 'Compilation
Unit @'  Compilation Unit @ offset 0x0:   Length:        0xfad
(32-bit)   Version:       2

----------------------------------------------------------------------
Martin_fr · 2023-09-01 14:51

Just a note: you can compile each unit with a different dwarf version
(you can probably even mix dwarf and stabs).

If your compiler and rtl is build with dwarf-2, and you compile your
app with dwarf-3 then you still use the ppu and o files from your pre-
build rtl (which have dwarf-2).

So, you should expect a mix of versions.

In principal such a mix is perfectly fine. The debugger can show the
data for each unit.

Using FpDebug there is an upside when having "dwarf 3 only". => Dwarf
does not make a distinction between a "AnsiString" and "PChar" (or in
some cases "array of char"). To be exact, it does not know the Pascal
string type.

Fpc makes tiny differences encoding those types. And FpDebug reacts to
those internals. => If you have any Dwarf-2 in the mix, then FpDebug
can't do that, and you may get results that have 2 values (FpDebug
returns Pchar and string / if/when it makes a diff).

Note that (on linux), even if you have a string in a unit that has
dwarf-3, if your rtl has dwarf-2 you still get the issues, because the
unit in your project may have pointers into the dwarf data from the
rtl, and therefore includes the dwarf-2 info.

Btw Fpc has -gw4  (at least in trunk)

----------------------------------------------------------------------
MarkMLl · 2023-09-01 15:00

I'm off this for at least a few hours, but will be back. However

Quote from: marcov on September 01, 2023, 03:49:33 pmProbably the
order is important with -gl triggering dwarf2, overriding an earlier
-gw3

No, definitely not. I'm explicitly using -gl -gw3 as shown at the
start of the script run, and I'm logging the actual parameters as part
of my FPC build (I put the script I use at
https://github.com/MarkMLl/fpclaz_build_scripts earlier today).

MarkMLl

----------------------------------------------------------------------
rvk · 2023-09-01 15:01

I thought the first entry was always the main program.
It seems to be that on amd64 the first unit is NOT the main program.

What is that si_prc.pp ??
And it seems that on amd64 there is always some units with version 3
(while I only have -gl in my options).


Code: Bash  [Select][+][-]window.onload = function(){var x1 =
document.getElementById("main_content_section"); if (x1) { var x =
document.getElementsByClassName("geshi");for (var i = 0; i
rik@XPS17:~/d$ fpc -gw2 dummyFree Pascal Compiler version 3.3.1
[2023/09/01] for x86_64Copyright (c) 1993-2023 by Florian Klaempfl and
othersTarget OS: Linux for x86-64Compiling dummy.pasLinking dummy5
lines compiled, 0.1 sec, 145520 bytes code, 58912 bytes
datarik@XPS17:~/d$ readelf --debug-dump=info dummy | grep -A 12
'Compilation Unit @' | grep "Version\|DW_AT_name"   Version:       3 
 <c>   DW_AT_name        : si_prc.pp   Version:       2    <2621>  
DW_AT_name        : dummy.pas   Version:       3    <2691>  
DW_AT_name        : system.pp

On arm64 the first is the main program:
Code: Bash  [Select][+][-]window.onload = function(){var x1 =
document.getElementById("main_content_section"); if (x1) { var x =
document.getElementsByClassName("geshi");for (var i = 0; i
root@8d805006b2cd:~/d# fpc -gw2 dummyFree Pascal Compiler version
3.3.1 [2023/09/01] for aarch64Copyright (c) 1993-2023 by Florian
Klaempfl and othersTarget OS: Linux for AArch64Compiling
dummy.pasAssembling testLinking dummy4 lines compiled, 0.3 sec, 166724
bytes code, 61042 bytes dataroot@8d805006b2cd:~/d# readelf --debug-
dump=info dummy | grep -A 12 'Compilation Unit @' | grep
"Version\|DW_AT_name"   Version:       2    <c>   DW_AT_name        :
dummy.pas   Version:       2    <87>   DW_AT_name        : system.pp

----------------------------------------------------------------------
rvk · 2023-09-01 15:08

New version with all units:
That seems to confirm the main program is compiled with DWARF 2.
But it is puzzling my whole FPC install is DWARF 3 (without giving
that option).

But seeing the first with only -gl is version 3 I think the default
changed to DWARF 3 on AMD64 (and not yet on ARM64).

Code: Bash  [Select][+][-]window.onload = function(){var x1 =
document.getElementById("main_content_section"); if (x1) { var x =
document.getElementsByClassName("geshi");for (var i = 0; i fpc
-odummy_ dummy.pasfpc -gl -odummy_gl dummy.pas   Version:       3   
<c>   DW_AT_name        : si_prc.pp   Version:       3    <2621>  
DW_AT_name        : dummy.pas   Version:       3    <2692>  
DW_AT_name        : system.pp   Version:       3    <47d48>  
DW_AT_name        : ../inc/lnfodwrf.pp   Version:       3    <49d4b> 
DW_AT_name        : ../inc/exeinfo.pp   Version:       3    <4ac0a>  
DW_AT_name        : ../inc/strings.ppfpc -gw2 -gl -odummy_gl_gw2
dummy.pas   Version:       3    <c>   DW_AT_name        : si_prc.pp 
 Version:       2    <2621>   DW_AT_name        : dummy.pas   Version:
      3    <2691>   DW_AT_name        : system.pp   Version:       3 
 <47d47>   DW_AT_name        : ../inc/lnfodwrf.pp   Version:       3 
 <49d4a>   DW_AT_name        : ../inc/exeinfo.pp   Version:       3  
<4ac09>   DW_AT_name        : ../inc/strings.ppfpc -gw3 -gl
-odummy_gl_gw3 dummy.pas   Version:       3    <c>   DW_AT_name      
 : si_prc.pp   Version:       3    <2621>   DW_AT_name        :
dummy.pas   Version:       3    <2692>   DW_AT_name        :
system.pp   Version:       3    <47d48>   DW_AT_name        :
../inc/lnfodwrf.pp   Version:       3    <49d4b>   DW_AT_name        :
../inc/exeinfo.pp   Version:       3    <4ac0a>   DW_AT_name        :
../inc/strings.ppfpc -gw2 -odummy_gw2 dummy.pas   Version:       3   
<c>   DW_AT_name        : si_prc.pp   Version:       2    <2621>  
DW_AT_name        : dummy.pas   Version:       3    <2691>  
DW_AT_name        : system.ppfpc -gw3 -odummy_gw3 dummy.pas   Version:
      3    <c>   DW_AT_name        : si_prc.pp   Version:       3   
<2621>   DW_AT_name        : dummy.pas   Version:       3    <2692>  
DW_AT_name        : system.pp1036446534 1035608 dummy_gw2152834824
1089568 dummy_gl_gw2222374223 1035616 dummy_gw34248296208 1089568
dummy_gl4248296208 1089568 dummy_gl_gw34276196424 206736 dummy_

----------------------------------------------------------------------
rvk · 2023-09-01 15:33

And finally a more readable version: (I won't bother you with further
spam  )

On ARM64 (compiled with an FPC with options -gl)
Code: Bash  [Select][+][-]window.onload = function(){var x1 =
document.getElementById("main_content_section"); if (x1) { var x =
document.getElementsByClassName("geshi");for (var i = 0; i
root@8d805006b2cd:~/d# sh tfpc  -odummy_ dummy.pas--fpc -gl -odummy_gl
dummy.pas   Version:       2 Unit         : dummy.pas   Version:     
2 Unit         : system.pp   Version:       2 Unit         :
../inc/lnfodwrf.pp   Version:       2 Unit         :
../inc/exeinfo.pp   Version:       2 Unit         : ../inc/strings.pp
--fpc -gw2 -gl -odummy_gw2_gl dummy.pas   Version:       2 Unit      
 : dummy.pas   Version:       2 Unit         : system.pp   Version:  
   2 Unit         : ../inc/lnfodwrf.pp   Version:       2 Unit       
: ../inc/exeinfo.pp   Version:       2 Unit         :
../inc/strings.pp--fpc -gw3 -gl -odummy_gw3_gl dummy.pas   Version:  
   3 Unit         : dummy.pas   Version:       2 Unit         :
system.pp   Version:       2 Unit         : ../inc/lnfodwrf.pp 
 Version:       2 Unit         : ../inc/exeinfo.pp   Version:       2
Unit         : ../inc/strings.pp--fpc -gw2 -odummy_gw2 dummy.pas 
 Version:       2 Unit         : dummy.pas   Version:       2 Unit   
    : system.pp--fpc -gw3 -odummy_gw3 dummy.pas   Version:       3
Unit         : dummy.pas   Version:       2 Unit         : system.pp--
1298906025 226696 dummy_162089040 1059192 dummy_gw21739967246 1118464
dummy_gw3_gl2552954366 1059192 dummy_gw33799279261 1118456
dummy_gl3799279261 1118456 dummy_gw2_gl
On AMD64 (compiled with an FPC with options -gl)
Code: Bash  [Select][+][-]window.onload = function(){var x1 =
document.getElementById("main_content_section"); if (x1) { var x =
document.getElementsByClassName("geshi");for (var i = 0; i
rik@XPS17:~/d$ sh tfpc  -odummy_ dummy.pas--fpc -gl -odummy_gl
dummy.pas   Version:       3 Unit         : si_prc.pp   Version:     
3 Unit         : dummy.pas   Version:       3 Unit         :
system.pp   Version:       3 Unit         : ../inc/lnfodwrf.pp 
 Version:       3 Unit         : ../inc/exeinfo.pp   Version:       3
Unit         : ../inc/strings.pp--fpc -gw2 -gl -odummy_gw2_gl
dummy.pas   Version:       3 Unit         : si_prc.pp   Version:     
2 Unit         : dummy.pas   Version:       3 Unit         :
system.pp   Version:       3 Unit         : ../inc/lnfodwrf.pp 
 Version:       3 Unit         : ../inc/exeinfo.pp   Version:       3
Unit         : ../inc/strings.pp--fpc -gw3 -gl -odummy_gw3_gl
dummy.pas   Version:       3 Unit         : si_prc.pp   Version:     
3 Unit         : dummy.pas   Version:       3 Unit         :
system.pp   Version:       3 Unit         : ../inc/lnfodwrf.pp 
 Version:       3 Unit         : ../inc/exeinfo.pp   Version:       3
Unit         : ../inc/strings.pp--fpc -gw2 -odummy_gw2 dummy.pas 
 Version:       3 Unit         : si_prc.pp   Version:       2 Unit   
    : dummy.pas   Version:       3 Unit         : system.pp--fpc -gw3
-odummy_gw3 dummy.pas   Version:       3 Unit         : si_prc.pp 
 Version:       3 Unit         : dummy.pas   Version:       3 Unit   
    : system.pp--1036446534 1035608 dummy_gw2152834824 1089568
dummy_gw2_gl222374223 1035616 dummy_gw34248296208 1089568
dummy_gl4248296208 1089568 dummy_gw3_gl4276196424 206736 dummy_
Adjusted script:
Code: Bash  [Select][+][-]window.onload = function(){var x1 =
document.getElementById("main_content_section"); if (x1) { var x =
document.getElementsByClassName("geshi");for (var i = 0; i
#!/bin/sh compile_and_check() {  echo "fpc $2 -o$1 dummy.pas"  fpc $2
-o$1 dummy.pas > /dev/null  readelf --debug-dump=info $1 | grep -A 12
'Compilation Unit @' | grep "Version\|DW_AT_name" | perl -0777 -pe
's/\n.*DW_AT_name/ Unit $1/g'  echo "--"} compile_and_check dummy_
""compile_and_check dummy_gl "-gl"compile_and_check dummy_gw2_gl "-gw2
-gl"compile_and_check dummy_gw3_gl "-gw3 -gl"compile_and_check
dummy_gw2 "-gw2"compile_and_check dummy_gw3 "-gw3" cksum dummy_* |
sortrm dummy_*
AMD64 definitely defaults to DWARF 3 while ARM64 does not.

----------------------------------------------------------------------
TRon · 2023-09-01 20:31

Quote from: rvk on September 01, 2023, 05:01:10 pmI thought the first
entry was always the main program.

It seems to be that on amd64 the first unit is NOT the main program.
As you discovered yourself, no (usually not for any platform/target).

QuoteWhat is that si_prc.pp ??
Startup & initialization code.

Before your main program is entered, the startup code also takes into
account the unit initializations/finalizations but more importantly
the startup code itself. Every platform/target has its own way of
pushing important information before your program startup into
registers and/or the stack. This differs for each platform and is even
dependable whether or not libc is used (that uses its own startup code
that has to be taken into account). Also before your program is able
to run the system unit needs to initialized so that it is able to work
on/for that target (which depends on target specific information).

That is why there also exist variations of the startup code.

----------------------------------------------------------------------
MarkMLl · 2023-09-02 07:53

Quote from: Martin_fr on August 31, 2023, 02:43:17 pmIn theory that
could be extended to gdbserver. But no plans for that at the moment.
Also: It's considerable slower.

I've found gdbserver indispensable when debugging anything which uses
low-numbered TCP ports. During normal operation access can be granted
using POSIX capabilities, but since these are lost if started using a
debugger the only realistic way is to run as root hence:

Code: Text  [Select][+][-]window.onload = function(){var x1 =
document.getElementById("main_content_section"); if (x1) { var x =
document.getElementsByClassName("geshi");for (var i = 0; i # gdbserver
:2345 ./Watchxxx-x86_64-linux-gtk2 
At that point the IDE can attach to port 2345, and the program being
tested barely knows it's there.

I know it's a long shot, but would it be possible to build a variant
of FpDebug which behaved like gdbserver, probably with an opaque
signalling protocol?

MarkMLl

----------------------------------------------------------------------
MarkMLl · 2023-09-02 08:43

If I build FPC (i.e. including runtimes etc.) for DWARF 4 and then run
the test script I posted earlier, I get

Code: Text  [Select][+][-]window.onload = function(){var x1 =
document.getElementById("main_content_section"); if (x1) { var x =
document.getElementsByClassName("geshi");for (var i = 0; i FPC
compiler/runtimes built with -gl -gw4.fpc -odummy_ dummy.pasfpc -gl
-odummy_gl dummy.pas  Compilation Unit @ offset 0:   Length:      
 0x1eda (32-bit)   Version:       4fpc -gl -gw2 -odummy_gl_gw2
dummy.pas  Compilation Unit @ offset 0:   Length:        0x1eda
(32-bit)   Version:       4fpc -gl -gw3 -odummy_gl_gw3 dummy.pas 
Compilation Unit @ offset 0:   Length:        0x1eda (32-bit) 
 Version:       4fpc -gw2 -odummy_gw2 dummy.pas  Compilation Unit @
offset 0:   Length:        0x1eda (32-bit)   Version:       4fpc -gw3
-odummy_gw3 dummy.pas  Compilation Unit @ offset 0:   Length:      
 0x1eda (32-bit)   Version:       43427178416 1029376
dummy_gl_gw33447956569 231872 dummy_3581180241 975368
dummy_gw23719963618 1029376 dummy_gl3719963618 1029376
dummy_gl_gw2656825139 975368 dummy_gw3 
So if nothing else it appears to imply that using readelf is a fairly
reliable way of getting the basic DWARF version even if the interplay
between the various compile-time options might possibly be slightly
non-intuitive (I'm certainly losing track of quite where we're at :-)

Having said which,

Code: Text  [Select][+][-]window.onload = function(){var x1 =
document.getElementById("main_content_section"); if (x1) { var x =
document.getElementsByClassName("geshi");for (var i = 0; i $ readelf
--debug-dump=info dummy_gw2 | grep -A 2 'Compilation Unit @' 
Compilation Unit @ offset 0:   Length:        0x1eda (32-bit) 
 Version:       4--  Compilation Unit @ offset 0x1ede:   Length:     
 0x6f (32-bit)   Version:       2--  Compilation Unit @ offset
0x1f51:   Length:        0x3c006 (32-bit)   Version:       4 
So the versioning exercise really boils down to looking at both the
RTL's startup code which could be reasonably expected to determine the
compiler's choice of default DWARF version, and the version which has
actually been used for the application code.

For this particular system based on Debian "Bookworm" x86_64, I'm
going to build FPC with DWARF 3 then ditto the Lazarus IDE. Once I've
done that, I'll see how happy the IDE is with gdb and FpDebug.

Noting Martin's comment that in principle the debugger should be happy
with a mix of DWARF (and possibly even stabs) versions, in practice
IDE+gdb appears unhappy with DWARF 2 and I think somebody's said that
FpDebug wanted DWARF 3 which seems to contradict his position. And
while I'm not a heavy user of Lazarus packages (i.e. via FpUpDeluxe
etc.) the possibility of a package carrying an incompatible DWARF-
version option around with it is slightly troubling.

Plus there's still also that dialogue which told me to specify a DWARF
version (including DWARF 2) without giving any information as to why
what a binary was actually using (which happened to be DWARF 2) was
considered to be a problem.

MarkMLl

----------------------------------------------------------------------
rvk · 2023-09-02 10:11

Quote from: MarkMLl on September 02, 2023, 10:43:38 amIf I build FPC
(i.e. including runtimes etc.) for DWARF 4 and then run the test
script I posted earlier,
The command I initially used only shows the first unit in the
executable.
But on AMD64, the first unit is a bootstrap si_prc.pp, which could
have a different DWARF version.

So you need to use the adjusted script from a few posts back to get a
clear picture of all used versions per unit.

So if for the stability you need a specific version of DWARF for all
units you would need to recompile all those units.

----------------------------------------------------------------------
MarkMLl · 2023-09-02 10:24

As you say, there were quite a few :-)

I've just got to the same place using

Code: Text  [Select][+][-]window.onload = function(){var x1 =
document.getElementById("main_content_section"); if (x1) { var x =
document.getElementsByClassName("geshi");for (var i = 0; i $ readelf
--debug-dump=info dummy_gl_gw2 | grep -A 7 'Compilation Unit @' |
egrep 'Version|_AT_' 
which also shows the compiler version: I think picking up packages
built elsewhere could be useful.

Using Perl for this is an obvious no-brainer, although the majority of
Pascal users seem to view Perl with the disdain that the majority of
Perl users reserve for Pascal :-)

MarkMLl

----------------------------------------------------------------------
rvk · 2023-09-02 10:29

Quote from: MarkMLl on September 02, 2023, 12:24:18 pmUsing Perl for
this is an obvious no-brainer, although the majority of Pascal users
seem to view Perl with the disdain that the majority of Perl users
reserve for Pascal :-)
Yeah, I wanted to show both DWARF version and unit on one line so it
would be a much nicer output. I couldn't get that done with just the
grep command 

What problems are there with fpdebug and mixing DWARF 2 and 3?

----------------------------------------------------------------------
MarkMLl · 2023-09-02 10:45

Quote from: rvk on September 02, 2023, 12:29:01 pmWhat problems are
there with fpdebug and mixing DWARF 2 and 3?

First problem was that as soon as I tried to switch to fpdebug it
presented me with a dialogue telling me to specify a DWARF version.
One of the options was DWARF 2, which I thought (and still think) I
was using. At that point I started looking at determining what was
actually in the binary...

However I've just discovered problems trying to do a complete Lazarus
2.2.4 build using my DWARF3-enabled FPC. I'll be back once I know what
I'm looking at...

MarkMLl

----------------------------------------------------------------------
rvk · 2023-09-02 13:16

Quote from: MarkMLl on September 02, 2023, 12:45:02 pmHowever I've
just discovered problems trying to do a complete Lazarus 2.2.4 build
using my DWARF3-enabled FPC.
What versions are you trying to mix?
I just tried complete recompile of fpc3.2.2 and laz2.2.4 with switch
-gl -gw3 and that works fine.
But normally I do all trunk.

BTW. Why are you still using 2.2.4 and not 2.2.6 with all the changes?
(Any special reasons?)
FPC 3.2.2 still defaults to DWARF 2 (so a complete recompile is needed
for FPC to get all 3).

Quotereadelf | head for ~/dev/fpc/bin/ppcx64
   Version:       3 Unit         : si_prc.pp
   Version:       3 Unit         : pp.pas
   Version:       3 Unit         : system.pp
   Version:       3 Unit         : ../inc/lnfodwrf.pp
   Version:       3 Unit         : ../inc/exeinfo.pp
   Version:       3 Unit         : ../inc/strings.pp
   Version:       3 Unit         : ../objpas/objpas.pp
   Version:       3 Unit         : catch.pas
   Version:       3 Unit         : globals.pas
   Version:       3 Unit         : compiler.pas
   Version:       3 Unit         : ../unix/baseunix.pp
   Version:       3 Unit         : ../unix/unix.pp
   Version:       3 Unit         : verbose.pas
   Version:       3 Unit         : ../unix/unixtype.pp
   Version:       3 Unit         : ../unix/unixutil.pp
   Version:       3 Unit         : ../unix/syscall.pp
   Version:       3 Unit         : ../unix/sysutils.pp
--
readelf | head for ~/dev/lazarus/lazarus
   Version:       3 Unit         : si_c.pp
   Version:       3 Unit         : lazarus.pp
   Version:       3 Unit         : system.pp
   Version:       3 Unit         : ../inc/lnfodwrf.pp
   Version:       3 Unit         : ../inc/exeinfo.pp
   Version:       3 Unit         : ../inc/strings.pp
   Version:       3 Unit         : ../inc/fpintres.pp
   Version:       3 Unit         : ../objpas/objpas.pp
   Version:       3 Unit         : ../unix/cthreads.pp
   Version:       3 Unit         : rtl-extra/src/unix/clocale.pp
   Version:       3 Unit         : ../unix/sysutils.pp
   Version:       3 Unit         : interfaces.pas
   Version:       3 Unit         : ideinstances.pas
   Version:       3 Unit         : forms.pp
   Version:       3 Unit         : lclproc.pas
   Version:       3 Unit         : ideoptionsintf.pas
   Version:       3 Unit         : lazconf.pp

----------------------------------------------------------------------
Martin_fr · 2023-09-02 13:50

Quote from: MarkMLl on September 02, 2023, 12:45:02 pmFirst problem
was that as soon as I tried to switch to fpdebug it presented me with
a dialogue telling me to specify a DWARF version. One of the options
was DWARF 2, which I thought (and still think) I was using. At that
point I started looking at determining what was actually in the
binary...

However I've just discovered problems trying to do a complete Lazarus
2.2.4 build using my DWARF3-enabled FPC. I'll be back once I know what
I'm looking at...

Well, the dialogue is the best we currently have.

The alternative is to set the default project (and package) options to
-gw2 (or maybe -gw3).

But it can't be told, if there are any targets (like embedded) where
that would not work. And it wouldn't fix existing projects. (nor
existing packages, and the info used for the RTL is currently
completely unknown to the IDE).

The dialog isn't ideal either. But at least it creates awareness.

The alternative would be just to hope that -g will produce dwarf. But
then if FpDebug starts, and no breakpoints work, no values in
watches.... => the user has no idea at all.

That currently is the case for packages (if ever -g would not be
dwarf). But at least users would see that the project code works in
the debugger. So some clue that the debugger is not entirely broken.

----------------------------------------------------------------------
MarkMLl · 2023-09-02 13:54

Quote from: rvk on September 02, 2023, 03:16:08 pmQuote from: MarkMLl
on September 02, 2023, 12:45:02 pmHowever I've just discovered
problems trying to do a complete Lazarus 2.2.4 build using my
DWARF3-enabled FPC.
What versions are you trying to mix?
I just tried complete recompile of fpc3.2.2 and laz2.2.4 with switch
-gl -gw3 and that works fine.
But normally I do all trunk.

BTW. Why are you still using 2.2.4 and not 2.2.6 with all the changes?
(Any special reasons?)
FPC 3.2.2 still defaults to DWARF 2 (so a complete recompile is needed
for FPC to get all 3).

FPC 3.2.2 built clean with -gl -gw3. Attempting to use that for
Lazarus 2.2.4

Code: Text  [Select][+][-]window.onload = function(){var x1 =
document.getElementById("main_content_section"); if (x1) { var x =
document.getElementsByClassName("geshi");for (var i = 0; i $ make
LCL_PLATFORM=gtk2 bigide 
or alternatively qt5. Result is

Code: Text  [Select][+][-]window.onload = function(){var x1 =
document.getElementById("main_content_section"); if (x1) { var x =
document.getElementsByClassName("geshi");for (var i = 0; i (9022)
Compiling resource ../units/x86_64-linux/nogui/lazbuild.or(9015)
Linking ../lazbuild/usr/bin/ld: /usr/local/share.lazarus/lazarus-
2.2.4+3.2.2/lcl/units/x86_64-linux/intfgraphics.o: in function
`.La16':intfgraphics.pas:(.debug_info+0x8975): undefined reference to
`DBG2_$SYSTEM_$$_IUNKNOWN'/usr/bin/ld: /usr/local/share.lazarus/lazaru
s-2.2.4+3.2.2/lcl/units/x86_64-linux/intfgraphics.o: in function
`.La18':intfgraphics.pas:(.debug_info+0x8a04): undefined reference to
`DBG2_$SYSTEM_$$_IUNKNOWN'/usr/bin/ld: /usr/local/share.lazarus/lazaru
s-2.2.4+3.2.2/lcl/units/x86_64-linux/graphics.o: in function
`.La151':graphics.pp:(.debug_info+0x1db3e): undefined reference to
`DBG2_$SYSTEM_$$_IUNKNOWN'/usr/bin/ld: /usr/local/share.lazarus/lazaru
s-2.2.4+3.2.2/lcl/units/x86_64-linux/graphics.o: in function
`.La152':graphics.pp:(.debug_info+0x1dbff): undefined reference to
`DBG2_$SYSTEM_$$_IUNKNOWN'/usr/bin/ld: /usr/local/share.lazarus/lazaru
s-2.2.4+3.2.2/lcl/units/x86_64-linux/imagelistcache.o: in function
`.La1':imagelistcache.pas:(.debug_info+0x184): undefined reference to
`DBG2_$SYSTEM_$$_IUNKNOWN'/usr/bin/ld: /usr/local/share.lazarus/lazaru
s-2.2.4+3.2.2/components/ideintf/units/x86_64-
linux/nogui/idehelpintf.o:idehelpintf.pas:(.debug_info+0xc29): more
undefined references to `DBG2_$SYSTEM_$$_IUNKNOWN' follow/usr/local/sh
are.lazarus/lazarus-2.2.4+3.2.2/ide/lazbuild.lpr(1878,1) Error: (9013)
Error while linking/usr/local/share.lazarus/lazarus-
2.2.4+3.2.2/ide/lazbuild.lpr(1878,1) Fatal: (10026) There were 1
errors compiling module, stoppingFatal: (1018) Compilation
abortedmake[2]: *** [Makefile:4673: lazbuild] Error 1make[2]: Leaving
directory '/usr/local/share.lazarus/lazarus-2.2.4+3.2.2/ide'make[1]:
*** [Makefile:5112: lazbuilder] Error 2make[1]: Leaving directory
'/usr/local/share.lazarus/lazarus-2.2.4+3.2.2/ide'make: ***
[Makefile:3820: lazbuild] Error 2 
I'd missed the announcement of 2.2.6. The combination of... well,
certain users... has had the result of my spending far less time
logged into the forum than I used to, and I gave up tracking trunk
when svn was abandoned.

Above appears reproducible, depending entirely on whether FPC 3.2.2 is
built with -gw2 (OK) or -gw3 (fails).

I'll take a look at 2.2.6 later in case it improves things, but I'm
resigned to being told that it's Debian's problem and no effort will
be put into fixing it.

Updated: fix unclosed quote. Apologies to the community for fouling
that up.

MarkMLl

----------------------------------------------------------------------
MarkMLl · 2023-09-02 13:58

Quote from: Martin_fr on September 02, 2023, 03:50:02 pmQuote from:
MarkMLl on September 02, 2023, 12:45:02 pmFirst problem was that as
soon as I tried to switch to fpdebug it presented me with a dialogue
telling me to specify a DWARF version. One of the options was DWARF 2,
which I thought (and still think) I was using. At that point I started
looking at determining what was actually in the binary...

However I've just discovered problems trying to do a complete Lazarus
2.2.4 build using my DWARF3-enabled FPC. I'll be back once I know what
I'm looking at...

Well, the dialogue is the best we currently have.

The alternative is to set the default project (and package) options to
-gw2 (or maybe -gw3).

But to the best of my knowledge the project was already using DWARF 2
since that's what FPC had been built for.

What was the dialogue trying to tell me: I assumed that it meant that
that the binary was in the wrong format, but was it actually just
trying to say that the project options should specify an explicit
debugger version? And if so what does FpDebug want?

MarkMLl

----------------------------------------------------------------------
Martin_fr · 2023-09-02 14:04

Quote from: MarkMLl on September 02, 2023, 03:58:27 pmQuote from:
Martin_fr on September 02, 2023, 03:50:02 pmQuote from: MarkMLl on
September 02, 2023, 12:45:02 pmFirst problem was that as soon as I
tried to switch to fpdebug it presented me with a dialogue telling me
to specify a DWARF version. One of the options was DWARF 2, which I
thought (and still think) I was using. At that point I started looking
at determining what was actually in the binary...

However I've just discovered problems trying to do a complete Lazarus
2.2.4 build using my DWARF3-enabled FPC. I'll be back once I know what
I'm looking at...

Well, the dialogue is the best we currently have.

The alternative is to set the default project (and package) options to
-gw2 (or maybe -gw3).

But to the best of my knowledge the project was already using DWARF 2
since that's what FPC had been built for.

What was the dialogue trying to tell me: I assumed that it meant that
that the binary was in the wrong format, but was it actually just
trying to say that the project options should specify an explicit
debugger version? And if so what does FpDebug want?

MarkMLl

The IDE only knows that the project settings are "-g"  (well and
package settings, but lets stick to the project).

The IDE does not know, what fpc does when it gets a "-g".
So for the IDE the setting must be explicit.

If the IDE could foretell what -g means to fpc => great. Then in a lot
of cases the dialog would not be needed.

Of course, it would be possible to
- first build (even if -g is given)
- then check, and report only if it went bad.

----------------------------------------------------------------------
rvk · 2023-09-02 14:07

Quote from: MarkMLl on September 02, 2023, 03:58:27 pmBut to the best
of my knowledge the project was already using DWARF 2 since that's
what FPC had been built for.

What was the dialogue trying to tell me: I assumed that it meant that
that the binary was in the wrong format, but was it actually just
trying to say that the project options should specify an explicit
debugger version? And if so what does FpDebug want?
The -g switch is default in Lazarus (when automatic) and that compiles
a default depending on the FPC version.
(or is it not certain that DWARF gets included in that case?)

FPC 3.2.2 (even compiled with -gw3) will generate version 2 for the
actual unit.
But it includes all needed units in the version for which FPC was
compiled itself (resulting in a mix of 2/3).

So compiling 3.2.2 with -gw3, will result in all versions 3 except
your own unit (when compiled with -g).

FPC 3.3.1 (trunk) will default to -gw3 and everything will be DWARF 3
anyway.

Of course... Lazarus could just scan the compiler and could know which
DWARF was used for your compiler version.

But I not sure if mixing 2 and 3 might lead to problems?

Edit:
Quote -g     Generate debug information (default format for
target)What are the defaults for which target?
According to this switch lazarus should now what target and debug info
was used.

----------------------------------------------------------------------
MarkMLl · 2023-09-03 10:36

Starting off with FPC 3.2.2 built using

Code: Text  [Select][+][-]window.onload = function(){var x1 =
document.getElementById("main_content_section"); if (x1) { var x =
document.getElementsByClassName("geshi");for (var i = 0; i $ make
NO_GDB=1 OVERRIDEVERSIONCHECK=1 OPT='-V3.2.2 -O- -gl -gw3 -Xs- -vt'
all |/usr/local/bin/fpc-filter-vt 
where the filter script
https://github.com/MarkMLl/fpclaz_build_scripts/blob/main/fpc-filter-
vt "pretty-prints" the file relationships.

If I compile Lazarus using

Code: Text  [Select][+][-]window.onload = function(){var x1 =
document.getElementById("main_content_section"); if (x1) { var x =
document.getElementsByClassName("geshi");for (var i = 0; i $ make
LCL_PLATFORM=qt5 FPCOPT='-gl -gw3' bigide 
...or for gtk2, version 2.2.6 appears OK while 2.2.4 fails with errors
relating to undefined reference to `DBG2_$SYSTEM_$$_IUNKNOWN'.

I can verify using readelf that all constituents of the lazarus binary
are now DWARF 3.

Changing the 2.2.4 build option to FPCOPT='-gl -gw2' doesn't fix this.

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'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.

MarkMLl

----------------------------------------------------------------------
MarkMLl · 2023-09-04 09:56

Quote from: MarkMLl on September 03, 2023, 12:36:13 pmMy 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.

QuoteI'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

----------------------------------------------------------------------
Martin_fr · 2023-09-04 10:20

Quote app still barfs.App or GDB? I assume GDB.

Btw, does gdb give a specific error? (The IDE dialog has a "more"
button).

Quote 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,Well, it could get the info using the
build in dwarf reader (that comes with fpdebug).

The difference is, that this can only happen *after* the build.

If you debug a project the size of the IDE, then you wait more than a
minute only to be told: Sorry, but we just noticed the settings for
that build were wrong. Please change them and wait another minute.

----------
The ideal case would be an "automatic by IDE" setting, where the IDE
decides what it thinks to be best. I.e. you change the debugger, and
the IDE may change the setting for you.

That would work for the project.

But packages like LCL, may be build via makefile (or maybe its just
lazbuild? I have no idea, I don't usually do much with those
Makefiles).
In the Makefiles, that decision can't be embedded.

So if we ship a prebuild in an installer, that still needs to be set
to some fixed dwarf setting. Or, alternatively, the first debug
session might rebuild the entire LCL (imagine you are a first time
user, your first hello world, and it takes over a minute to start.)

Yes, ok the dialogue isn't great for a first time user either. But it
is meant to be "if you don't know, press ok"

----------------------------------------------------------------------
Martin_fr · 2023-09-04 10:24

Debug info on the RTL isn't a "new user" problem => the default in the
installer does not have any debug info for the RTL.

For LCL and such packages: It is an issue, and unsolved.

Especially since any default is somewhat bad:
- Dwarf 2 gives a less good experience if using FpDebug
- Dwarf 3 may be more troublesome with GDB.

Ultimately, the user needs to be made aware at some point.

----------------------------------------------------------------------
MarkMLl · 2023-09-04 12:35

Quote from: Martin_fr on September 04, 2023, 12:24:11 pmDebug info on
the RTL isn't a "new user" problem => the default in the installer
does not have any debug info for the RTL.

Presumably you mean sudo make install... there. But if I look at
/usr/local/lib/fpc/3.2.2/ppcx64 I can still get the DWARF versions of
the individual units that went into it... also if I single out e.g.
system.o I can see it's not stripped.

However the issue in that dialogue isn't so much that it's failing to
pick up the DWARF version that the target of the current project is
carrying around (if any), it's that it's unclear whether it's saying
"you need an explicit setting in the IDE, not just -g" or "your
existing binaries are all broken in some way" at which point it's of
considerable interest to be able to inspect existing binaries to find
out what's going on (hence the kerfuffle about readelf).

And the problem with using -g appears to be that in at least some
cases it implies -gw2, even if the compiler was consistently built
using the -gw3 option (which it /should/ be able to determine).

MarkMLl

p.s. I'll take a bit more of a look at error messages etc. (i.e. your
other message) in a few minutes. But I'm still annoyed from having
somebody criticise me in court a few days ago for "spending all my
time playing with obsolete languages on obsolete hardware".

----------------------------------------------------------------------
Martin_fr · 2023-09-04 13:06

Quote from: MarkMLl on September 04, 2023, 02:35:59 pmQuote from:
Martin_fr on September 04, 2023, 12:24:11 pmDebug info on the RTL
isn't a "new user" problem => the default in the installer does not
have any debug info for the RTL.

Presumably you mean sudo make install... there.
Nope, the download able installer (rpm, dep, inno setup,...)

QuoteBut if I look at /usr/local/lib/fpc/3.2.2/ppcx64 I can still get
the DWARF versions of the individual units that went into it... also
if I single out e.g. system.o I can see it's not stripped.
I haven't checked the rpm/dep, but the inno setup has an fpc build
without any dwarf.

QuoteHowever the issue in that dialogue isn't so much that it's
failing to pick up the DWARF version that the target of the current
project is carrying around (if any), it's that it's unclear whether
it's saying "you need an explicit setting in the IDE, not just -g" or
"your existing binaries are all broken in some way" at which point
it's of considerable interest to be able to inspect existing binaries
to find out what's going on (hence the kerfuffle about readelf).
Does the average user really assume that the "binaries" differ from
the "settings"?

Also, (again) at the time of the dialog, the binaries don't exist. The
project hasn't been compiled yet.

At best, the ppu of packages and rtl exist (and those ppu can have
different info than the fpc exe. I use a fully optimized fpc/ppc, but
have an RTL with debug info and -O1 // but then that is not an average
setup)

At current, the IDE only pays attention to the debug info of the
project (units that are part of the project).
Yes, that is an issue, packages should be checked too. But I haven't
got any good idea how to do that (other than rewriting half of the IDE
build system, and that is not currently an option).

QuoteAnd the problem with using -g appears to be that in at least some
cases it implies -gw2, even if the compiler was consistently built
using the -gw3 option (which it /should/ be able to determine).
Yes, and the IDE doesn't know (in advance) when that is the case and
when it isn't.

I am still not clear how to improve the wording on the dialog.

Maybe other than adding "if uncertain, then use DWARF 3" (or maybe
"DWARF 2" ? Because if that user ever switches to gdb .....)

I don't think that a text like
"The IDE doesn't know what the compiler will do with your current
settings, so please help it by specifying a more concrete setting"
will be better?



IMHO the entire underlaying concept isn't suitable.
But that is a lot of work, and currently not on the horizon (not
fitting on my todo list)


If you think you have a better text, well the text is easy to be
changed.

----------------------------------------------------------------------
MarkMLl · 2023-09-04 13:29

Quote from: Martin_fr on September 04, 2023, 12:20:11 pmQuote app
still barfs.App or GDB? I assume GDB.

GDB while debugging app, i.e. as distinct from anything that happened
while building Lazarus or the compiler.

OK, FPC 3.2.2 built from scratch with $ make NO_GDB=1
OVERRIDEVERSIONCHECK=1 OPT='-V3.2.2 -O- -gl -gw2 -godwarfsets -Xs-
-vt' all |/usr/local/bin/fpc-filter-vt and Lazarus 2.2.4 built with $
make LCL_PLATFORM=gtk2 FPCOPT='-gl -gw2 -godwarfsets' bigide.

I've got a breakpoint on a specific procedure call in my app. Doing a
"Step into" at that point I get a gdb dialogue, and using "More" I get

Code: Text  [Select][+][-]window.onload = function(){var x1 =
document.getElementById("main_content_section"); if (x1) { var x =
document.getElementsByClassName("geshi");for (var i = 0; i While
executing the command: "TGDBMIDebuggerInstruction: "ptype RESULT",
[ifRequiresThread, ifRequiresStackFrame, ifRequiresMemLimit,
ifRequiresArrayLimit] Thr=1 Frm=0"gdb reported:"&"A fatal error
internal to GDB has been detected, further\ndebugging is not possible.
 GDB will now terminate.\n\n"&"This is a bug, please report it."" 
I'm fairly sure this is reproducible, and if necessary I could bundle
up the entire project with test files etc.

MarkMLl

----------------------------------------------------------------------
Martin_fr · 2023-09-04 14:00

Quote from: MarkMLl on September 04, 2023, 03:29:41 pmI'm fairly sure
this is reproducible, and if necessary I could bundle up the entire
project with test files etc.

Not necessary...

I was just curious, some gdb print a full assertion message,
indicating what there problem is. Even then, little to be done.

Those gdb crashes can be caused by either gdb or fpc.

That is, gdb may (and observed by me: has) crashed on valid dwarf
info.

But fpc has/had bugs, writing incorrect dwarf info.
(In that case fpc fixes may help)

----------------------------------------------------------------------
MarkMLl · 2023-09-04 16:14

Quote from: Martin_fr on September 04, 2023, 04:00:18 pmBut fpc
has/had bugs, writing incorrect dwarf info.
(In that case fpc fixes may help)

Using today's fixes AKA 3.2.3, no change unfortunately.

MarkMLl