## Summary I was working on a project to use cimgui + cimplot (already works after these fixes) but I fount that, FPC's internal linker for PE/COFF on Windows x86_64 discards `.ctors`, `.dtors`, and `.text.startup` sections from GCC/MinGW object files during dead-code elimination (`RemoveUnreferencedSections`). This causes C++ static constructors to never be registered in `__CTOR_LIST__`, so runtime-initialized `static const` data in `.bss` remains all zeros. ## System Information - **Operating system:** Windows 11 Pro (10.0.26100) - **Processor architecture:** x86-64 - **Compiler version:** FPC trunk - **Device:** Computer ## Steps to reproduce 1. C++ library with GCC/MinGW that contains `static const` arrays of structs with C++ constructors. e.g.: ```cpp struct DateTimeSpec { int Date; int Time; bool UseISO8601; bool Use24HourClock; // Default constructor DateTimeSpec() {} // Parameterized constructor — this is what makes GCC use .ctors DateTimeSpec(int date_fmt, int time_fmt, bool iso, bool use24h) { Date = date_fmt; Time = time_fmt; UseISO8601 = iso; Use24HourClock = use24h; } }; static const DateTimeSpec g_TimeFormats[8] = { DateTimeSpec(0, 1, false, false), DateTimeSpec(1, 2, true, false), // ... more initializers }; ``` 2. Compiled with build_ctors.bat in LinkerBug.zip. 3. At runtime, access the static const data, it will be all zeros. Example Project A minimal reproducer [LinkerBug.zip](/uploads/2c595d12a361189bbc249f9640496501/LinkerBug.zip) project linking ctors_test.o (built from ctors_test.cpp via MinGW GCC) It uses C++ static const array of a struct type that has a user-defined constructor, compiled with GCC for Win64 COFF and linked via FPC's internal linker. What is the current bug behavior? Because DateTimeSpec has a C++ constructor, GCC cannot evaluate the initialization at compile time. Instead, GCC: 1. Places the array in .bss (zero-initialized, PE_SCN_CNT_UNINITIALIZED_DATA) 2. Generates a static constructor function _GLOBAL__sub_I_* in the .text.startup section 3. Registers it via a pointer in the .ctors section FPC's internal linker includes .ctors in the output (via OBJSECTION .ctor* in the linker script, between __CTOR_LIST__ markers). However, during RemoveUnreferencedSections, the .ctors and .text.startup sections are garbage-collected because nothing in the FPC code directly references them. The resulting __CTOR_LIST__ is {-1, 0} (empty). Since no static constructors run, the .bss data stays zero. At runtime, pointers to this data resolve to valid addresses in the .bss region, but the data is all zeros. When linking the same .o/.a file with a C main() via GNU ld, the GCC CRT startup calls __main() which iterates __CTOR_LIST__ and runs all static constructors, so the data is correctly initialized. What is the expected (correct) behavior? The .ctors, .dtors, and .text.startup sections from external COFF objects should be preserved (not garbage-collected), so that __CTOR_LIST__ contains the static constructor pointers. At runtime, C++ static constructors should execute, initializing all runtime-initialized static const data.(Or maybe this can be done by the user !?) ## Relevant logs and/or screenshots Running both test files C and Pascal: Output from a C-linked executable calling debug_check_timeformat (correct): ``` GCC-linked result (should have correct data): === DateTimeSpec table (initialized via .ctors) === [0] Date=0 Time=1 ISO=0 24H=0 [1] Date=1 Time=2 ISO=1 24H=0 [2] Date=2 Time=3 ISO=0 24H=1 [3] Date=3 Time=4 ISO=1 24H=1 [4] Date=4 Time=5 ISO=0 24H=0 [5] Date=5 Time=6 ISO=1 24H=0 [6] Date=6 Time=7 ISO=0 24H=1 [7] Date=7 Time=8 ISO=1 24H=1 === Raw bytes of g_TimeFormats === 00 00 00 00 01 00 00 00 00 00 00 00 01 00 00 00 02 00 00 00 01 00 00 00 02 00 00 00 03 00 00 00 00 01 00 00 03 00 00 00 04 00 00 00 01 01 00 00 04 00 00 00 05 00 00 00 00 00 00 00 05 00 00 00 06 00 00 00 01 00 00 00 06 00 00 00 07 00 00 00 00 01 00 00 07 00 00 00 08 00 00 00 01 01 00 00 === Simple int array (compile-time .rdata) === g_SimpleValues[0] = 0xDEAD g_SimpleValues[1] = 0xBEEF g_SimpleValues[2] = 0xCAFE g_SimpleValues[3] = 0xF00D ``` Output from the FPC-linked executable calling debug_check_timeformat (broken): ``` FPC-linked result (likely all zeros for constructor data): === FPC .ctors Section Bug Reproduction === === DateTimeSpec table (initialized via .ctors) === [0] Date=0 Time=0 ISO=0 24H=0 [1] Date=0 Time=0 ISO=0 24H=0 [2] Date=0 Time=0 ISO=0 24H=0 [3] Date=0 Time=0 ISO=0 24H=0 [4] Date=0 Time=0 ISO=0 24H=0 [5] Date=0 Time=0 ISO=0 24H=0 [6] Date=0 Time=0 ISO=0 24H=0 [7] Date=0 Time=0 ISO=0 24H=0 === Raw bytes of g_TimeFormats === 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 === Simple int array (compile-time .rdata) === g_SimpleValues[0] = 0xDEAD g_SimpleValues[1] = 0xBEEF g_SimpleValues[2] = 0xCAFE g_SimpleValues[3] = 0xF00D === Verification from Pascal === DateTimeSpec (needs .ctors to initialize): get_datetime_date(0) = 0 get_datetime_date(1) = 0 get_datetime_date(2) = 0 get_datetime_date(3) = 0 get_datetime_date(4) = 0 get_datetime_date(5) = 0 get_datetime_date(6) = 0 get_datetime_date(7) = 0 Simple values (compile-time .rdata): get_simple_value(0) = 0xDEAD get_simple_value(1) = 0xBEEF get_simple_value(2) = 0xCAFE get_simple_value(3) = 0xF00D *** BUG CONFIRMED *** Constructor-initialized data is ALL ZEROS (.ctors stripped) Compile-time .rdata is correct (not affected) ``` __CTOR_LIST__ in the FPC executable is empty (just the -1 start marker and 0 end marker, no constructor pointers between them). ### Possible fixes This line `+ if (relocsec.objdata=objsec.objdata) and (Assigned(relocsec.ExeSection)) then` in the diff patch is from An old issue https://gitlab.com/freepascal.org/fpc/source/-/work_items/40548 Linker: preserve C++ constructor/destructor sections (required) In compiler/ogcoff.pas, around line 2842, the section-keep logic already preserves .edata, .rsrc, .fpc, and .idata sections. Add .ctors, .dtors, and .text.startup to this list: ```patch diff --git a/compiler/ogcoff.pas b/compiler/ogcoff.pas index 1634adad..7b232a5d 100644 --- a/compiler/ogcoff.pas +++ b/compiler/ogcoff.pas @@ -1435,7 +1435,7 @@ implementation RELOC_SECREL32 : begin { fixup address when the symbol was known in defined object } - if (relocsec.objdata=objsec.objdata) then + if (relocsec.objdata=objsec.objdata) and (Assigned(relocsec.ExeSection)) then dec(address,relocsec.ExeSection.MemPos); inc(address,relocval); end; @@ -2839,7 +2839,7 @@ multi = record secoptions:=djdecodesechdrflags(secname,sechdr.flags); secalign:=sizeof(pint); end; - if (Length(secname)>3) and (secname[2] in ['e','f','i','p','r']) then + if (Length(secname)>3) and (secname[2] in ['c','d','e','f','i','p','r','t']) then begin if (Pos('.edata',secname)=1) or (Pos('.rsrc',secname)=1) or @@ -2852,6 +2852,12 @@ multi = record include(secoptions,oso_keep); secname:=secname + '.' + ExtractFileName(InputFileName); end; + { Keep C/C++ static constructor/destructor sections and their + code so they survive RemoveUnreferencedSections } + if (Pos('.ctors',secname)=1) or + (Pos('.dtors',secname)=1) or + (Pos('.text.startup',secname)=1) then + include(secoptions,oso_keep); end; objsec:=TCoffObjSection(createsection(secname,secalign,secoptions,false)); FSecTbl[i]:=objsec; ``` RTL: call C++ static constructors at startup FPC's _mainCRTStartup (in the sysinit unit) should iterate __CTOR_LIST__ and call all registered constructors before calling _FPC_EXE_Entry. Currently it does not. This is analogous to GCC's CRT calling __main(). If not implemented, users must manually call __main or iterate __CTOR_LIST__ from their Pascal code: ```pascal procedure __main; cdecl; external; begin __main; // initialize C++ static data // ... rest of program end. ``` or something like ```pascal unit CPPInit; {$mode ObjFPC}{$H+} interface implementation type TCtorFunc = procedure; cdecl; PCtorFunc = ^TCtorFunc; var __CTOR_LIST__: PtrInt; cvar; external; procedure RunCppConstructors(); var p: PCtorFunc; begin p := @__CTOR_LIST__; Inc(p); // skip the -1 marker while p^ <> nil do begin p^(); Inc(p); end; end; initialization RunCppConstructors(); end. ``` The Linker Fix is required to ensures the data is present in the executable, But for the RTL fix I'm not sure it can be added! But it's needed runtime initialization but as mentioned If not implemented then users can do it manually based on the project.