See the example below. Complied on Linux and windows.  (fpc 3.3.1)    fpc  -O- -gw3   project.lpr

then using
  strings project | grep TLIST

On linux entries for *all* methods of TList are present. On Windows that is NOT the case.

Why?

program Project1;
uses classes;
var l: TList;
begin
   l := TList.Create;
   l.add(nil);
end.

Martin Frb via fpc-devel schrieb am Fr.,
24. Apr. 2026, 17:13:

On Windows the internal linker can better omit unused sections while debug information is enabled while with ELF it can't.

Regards,
Sven

Is there an option to turn that "better" off?

As a user (if I hadn't learned how to deal with FPC debug differences to other development tools), I would expect those not to be stripped.

As a user, if I used a TList in my app, I would want to be able to evaluate    SomeList.GetCount()

This didn't matter when GDB couldn't watch function call results. But now we have an alternative.

---------------
Actually, what debuggers are used by core team members? Anyone still using gdb in some cases (including OOP targets?)

---------------
Btw, any idea where the compiler stores the target pointer size?

The code currently uses
    tai_const.create_8bit(sizeof(pint))

But that can't be right when cross compiling?

BST Martin Frb wrote

Is there an option to turn that "better" off?

+1

I would have expected -O- to disable all optimisations.

Regards,
Graeme

BST Martin Frb wrote

Btw, any idea where the compiler stores the target pointer size?

I believe what you are looking for is voidpointertype.size - it is the correct target-aware pointer size in the FPC compiler.

- sizeof(pint) — reflects the host compiler's pointer size (wrong for cross- compilation)
- voidpointertype.size — reflects the target pointer size (set during psystem.pas initialisation based on the target CPU)

Interestingly, that means dbgdwarf.pas:3317 has a bug with tai_const.create_8bit(sizeof(pint)) for the DWARF address_size field.

The code should read:

inc(G_ByteCounter, voidpointertype.size)

voidpointertype is declared in symdef.pas and is always available once the system unit types are initialised. You can see psystem.pas:206 uses case voidpointertype.size of to decide which integer types map to pointer-sized integers — it's the established idiom for this.

I'll test a bit later and open a MR in my initial investigation is correct.

Regards
Graeme

BST Martin Frb wrote

The code currently uses tai_const.create_8bit(sizeof(pint)) But that can't be right when cross compiling?

I've created a MR. There were 7 locations that needed fixing.

https://gitlab.com/freepascal.org/fpc/source/-/merge_requests/1450

Regards,
Graeme

BST Martin Frb wrote

The code currently uses tai_const.create_8bit(sizeof(pint)) But that can't be right when cross compiling?

Hi all,

I recently looked into whether sizeof(pint) in dbgdwarf.pas was producing incorrect DWARF address_size values during cross-compilation — specifically the concern that on a 64-bit host generating 32-bit debug info, sizeof(pint) would evaluate to 8 rather than 4.

The short answer is: it doesn't, and the code is correct as-is.

The reason I initially thought it might be a problem is the common assumption that sizeof(pint) reflects the host pointer size. That is true in user programs, but not for FPC's cross-compiler binaries. When ppcross386 is built, the compiler source is compiled with -dCPU_I386, which sets {$define CPU32}, which in turn causes PtrInt (= pint, Pascal being case-insensitive) to be defined as Longint — 4 bytes — regardless of the host architecture the binary runs on. So sizeof(pint) evaluates to the target pointer size at Pascal compile time, which is exactly what you want.

I verified this with a small test. Compiling a trivial program using ppcross386 on an x86_64 host with debug info:

----
program dwarftest;
var
  x: LongInt;
begin
  x := 42;
  WriteLn(x);
end.
----

$ ppcross386 -g -Cn dwarftest.pas
Free Pascal Compiler version 3.3.1 [2026/04/25] for i386 ...

$ readelf --debug-dump=info dwarftest.o | grep -A5 "Compilation Unit" Compilation Unit @ offset 0:
Length: 0x85 (32-bit)
Version: 3
Abbrev Offset: 0
Pointer Size: 4

Pointer Size: 4 is correct for an i386 target. A patched build using voidpointertype.size produces identical output, confirming the two expressions are always equivalent.

I've closed the MR I had opened for this.

Graeme

25. dubna 2026 0:57:16 SELČ, Martin Frb via fpc-devel napsal:

On 25/04/2026 00:10, Sven Barth via fpc-devel wrote: > Martin Frb via fpc-devel schrieb am Fr., 24. Apr. 2026, 17:13:

.
.

Actually, what debuggers are used by core team members? Anyone still using gdb in some cases (including OOP targets?)

.
.

Not sure what is meant with OOP in this context, but there's no other option for OS/2 than GDB with stabs (not because there wouldn't be other debuggers available, but because neither me nor anybody else managed to provide support for them (since it wouldn't be "just" implementing support for something else, but rather to solve a bunch of other issues first - at least different object format and different linker).

Tomas

I was wondering if it is an issue just with the GDB I have or a general issue.

Though, I did not test stabs.

There is some old, incorrect DWARF code that generates wrong info for
   type TFoo = class
     public const X = 1;
   end;

And, that causes an assert failure in gdb (at least mine).

But, that never was a big issue => likely no one ever spotted it, because such constants are rare.
Or well, used to be.

Now TObject itself (in 331) has one of them. And gdb gives an issue.

Then again, no one seems to have been bothered by it (other than me occidentally stumbling on it). Because
- I saw no mention
- I saw no attempt to fix it

So I wasn't sure, maybe my GDB is just bad...

Try above, with DWARF.
To inspect the variable
  var MyFoo: TFoo; //MyFoo:= TFoo.create;

in GDB
  p MyFoo^

without deref, gdb only prints the address.

---------------------
There are various fixes.

remove those constants completely from DWARF => but I don't know if that is object/record only.  This may be some other

TDebugInfoDwarf.enum_membersyms_callback => which is called in a few places calls
TDebugInfoDwarf.appendsym_const_member
which adds
          append_entry(DW_TAG_member,false,

That looks like in classes/records only...

------------------
Alternatively make it dependent on godwarfcpp
Because, despite it being wrong => FpDebug deals with it.

(And even one of the DWARF maintainers (I think it was) has recently (on a diff subject) told me:
 If the debugger can read it, just use tags/attribs that aren't meant in that place.

But, I think that wouldn't be worth it.... Just go with the below instead.

--------------
And of course, lets do DWARF 5
Because there is an official solution.

And for constants it works with GDB (I think, I done a ton of diff testing, so hope not to mix up results)

For "class var" also official supported, GDB fails...

Latest GDB has lots of "for each language C, Pascal, ...", and that broke some previously working stuff...

...

I did re-run some of my gdb tests v12 and v17 on Win64

When forcing "set language = c++" then gdb accepts the dwarf info. Any of
- the current wrong one
- DWRAF-5 TAG_Variable  (even when dwarf version is set to lower than 5)

When the language is pascal, gdb will fail that in any case. It will try to check for a bit offset, but as their is no bitoffset attribute, that triggers an assert.
That is an issue in gdb.

I found comments in gdb that state "there may be other value, but we haven't seen them used, so they aren't implemented" => and gdb introduces more and more language dependent code.

------------------------
In any case, that means (probably / not explicitly tested) when using -godwarfcpp  the current info is workable for gdb.

Question is, what to do when -godwarfcpp isn't given? Assume that the debugger will be FpDebug (that is only true for a few platforms)

Add a -godwarfFpDebug ?

Just apply the Dwarf-5 MR
https://gitlab.com/freepascal.org/fpc/source/-/merge_requests/1447 , and fix it for Dwarf-5 => making Dwarf-5 the go to for fpdebug? (and any other debugger if it implements this)
(adding TAG_Variable for that case would be easy)