Re: [fpc-pascal] Corba ABI change ?

2026-02-20 Thread Tony Whyman via fpc-pascal
Well, the good news is that you have a proof that the TObject layout 
change is the cause of your problem. The bad news is that you either 
have to live with a non-standard build of the compiler/rtl or update 
your code.


On 19/02/2026 17:52, Adriaan van Os via fpc-pascal wrote:

Marc Weustink via fpc-pascal wrote:

In our case advanced records are not an option since a large part of 
the codebase is still used by that old delphi.

That will mean that we need to stick to 3.2


With a few changes, I built 3.3.1 trunk without Monitor support (on 
MacOS), so without the TObject ABI change. It worked fine.


Regards,

Adriaan van Os
___
fpc-pascal maillist  -  [email protected]
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

___
fpc-pascal maillist  -  [email protected]
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal


Re: [fpc-pascal] Corba ABI change ?

2026-02-19 Thread Adriaan van Os via fpc-pascal

Marc Weustink via fpc-pascal wrote:

In our case advanced records are not an option since a large part of the 
codebase is still used by that old delphi.

That will mean that we need to stick to 3.2


With a few changes, I built 3.3.1 trunk without Monitor support (on MacOS), so without the TObject 
ABI change. It worked fine.


Regards,

Adriaan van Os
___
fpc-pascal maillist  -  [email protected]
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal


Re: [fpc-pascal] Corba ABI change ?

2026-02-19 Thread Marc Weustink via fpc-pascal




On 19/02/2026 14:15, Michael Van Canneyt via fpc-pascal wrote:



On Thu, 19 Feb 2026, Marc Weustink via fpc-pascal wrote:

Pfew.. when you initially wrote your "observations" I didn't realize 
this issue.
In our product, based on old delphi code, an object is used as "record 
with methods" to interface with various IP based systems.


if you are referring to old TP style objects, your code is unaffected.
It only applies to Delphi-style objects.


sorry for the noise, misread "class" (and I never expected that someone 
would use class style objects laid over external data)


Marc
___
fpc-pascal maillist  -  [email protected]
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal


Re: [fpc-pascal] Corba ABI change ?

2026-02-19 Thread Michael Van Canneyt via fpc-pascal



On Thu, 19 Feb 2026, Marc Weustink via fpc-pascal wrote:




On 18/02/2026 10:34, Tony Whyman via fpc-pascal wrote:
Supplementing my point below, I went back and checked my notes. The 
TObject layout post 3.2 (in my copy of trunk) is now


        TObject = class
        {$IFDEF SYSTEM_HAS_FEATURE_MONITOR}
        strict private
           _MonitorData : Pointer;
        private
           function SetMonitorData(aData,aCheckOld : Pointer) : Pointer; 
inline;

           function GetMonitorData: Pointer; inline;
        {$ENDIF}
        protected
           function GetDisposed : Boolean; inline;
           Property Disposed : Boolean Read GetDisposed;
        public

with everything before "public" having been added. The big change is the 
addition of "_MonitorData". This bumps the offset of all later fields up 
by sizeof(pointer). If you have code that makes assumptions about the 
object layout - and this very much applies to code that tries to import 
an object from C++ then your previous assumptions are invalid.


Pfew.. when you initially wrote your "observations" I didn't realize 
this issue.
In our product, based on old delphi code, an object is used as "record 
with methods" to interface with various IP based systems.


if you are referring to old TP style objects, your code is unaffected.
It only applies to Delphi-style objects.

Michael.___
fpc-pascal maillist  -  [email protected]
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal


Re: [fpc-pascal] Corba ABI change ?

2026-02-19 Thread Marc Weustink via fpc-pascal



On 18/02/2026 10:34, Tony Whyman via fpc-pascal wrote:
Supplementing my point below, I went back and checked my notes. The 
TObject layout post 3.2 (in my copy of trunk) is now


        TObject = class
        {$IFDEF SYSTEM_HAS_FEATURE_MONITOR}
        strict private
           _MonitorData : Pointer;
        private
           function SetMonitorData(aData,aCheckOld : Pointer) : Pointer; 
inline;

           function GetMonitorData: Pointer; inline;
        {$ENDIF}
        protected
           function GetDisposed : Boolean; inline;
           Property Disposed : Boolean Read GetDisposed;
        public

with everything before "public" having been added. The big change is the 
addition of "_MonitorData". This bumps the offset of all later fields up 
by sizeof(pointer). If you have code that makes assumptions about the 
object layout - and this very much applies to code that tries to import 
an object from C++ then your previous assumptions are invalid.


Pfew.. when you initially wrote your "observations" I didn't realize 
this issue.
In our product, based on old delphi code, an object is used as "record 
with methods" to interface with various IP based systems. The methods 
are used for dissecting packets, endianes conversions, bit fiddling, 
flag handling etc.

As long as no virtuals were used, an object hadn't any memory overhead.

The advice I got was that for external interfaces, only the "record" 
layout is immutable between versions. In the end, I had to remove all 
the Firebird interface code that relied on the assumption that the 
Pascal object layout was the same as the C++ and replaced it with 
extended records in order to mimimise the impact on code that used the API.


In our case advanced records are not an option since a large part of the 
codebase is still used by that old delphi.

That will mean that we need to stick to 3.2

Thanks for warning.
Marc

___
fpc-pascal maillist  -  [email protected]
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal


Re: [fpc-pascal] Corba ABI change ?

2026-02-18 Thread Tony Whyman via fpc-pascal
SYSTEM_HAS_FEATURE_MONITOR seems to be on by default - I never 
explicitly turned it on, so it probably is the default.


Turning SYSTEM_HAS_FEATURE_MONITOR off may be a good way to show that 
this is the problem and a short term workaround, but if you are 
providing source code that you expect to be widely used then you 
probably need to fix the issue with SYSTEM_HAS_FEATURE_MONITOR turned on.


On 18/02/2026 16:25, Adriaan van Os via fpc-pascal wrote:

Tony Whyman via fpc-pascal wrote:



Supplementing my point below, I went back and checked my notes. The 
TObject layout post 3.2 (in my copy of trunk) is now


   TObject = class
   {$IFDEF SYSTEM_HAS_FEATURE_MONITOR}
   strict private
  _MonitorData : Pointer;
   private
  function SetMonitorData(aData,aCheckOld : Pointer) : 
Pointer; inline;

  function GetMonitorData: Pointer; inline;
   {$ENDIF}
   protected
  function GetDisposed : Boolean; inline;
  Property Disposed : Boolean Read GetDisposed;
   public

with everything before "public" having been added. The big change is 
the addition of "_MonitorData". This bumps the offset of all later 
fields up by sizeof(pointer). If you have code that makes assumptions 
about the object layout - and this very much applies to code that 
tries to import an object from C++ then your previous assumptions are 
invalid.


Is SYSTEM_HAS_FEATURE_MONITOR defined by default in the build process 
? I assume, the compiler can be built without it ?


Regards,

Adriaan van Os ___
fpc-pascal maillist  -  [email protected]
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal


Re: [fpc-pascal] Corba ABI change ?

2026-02-18 Thread Adriaan van Os via fpc-pascal

Tony Whyman via fpc-pascal wrote:



Supplementing my point below, I went back and checked my notes. The 
TObject layout post 3.2 (in my copy of trunk) is now


   TObject = class
   {$IFDEF SYSTEM_HAS_FEATURE_MONITOR}
   strict private
  _MonitorData : Pointer;
   private
  function SetMonitorData(aData,aCheckOld : Pointer) : Pointer; 
inline;

  function GetMonitorData: Pointer; inline;
   {$ENDIF}
   protected
  function GetDisposed : Boolean; inline;
  Property Disposed : Boolean Read GetDisposed;
   public

with everything before "public" having been added. The big change is the 
addition of "_MonitorData". This bumps the offset of all later fields up 
by sizeof(pointer). If you have code that makes assumptions about the 
object layout - and this very much applies to code that tries to import 
an object from C++ then your previous assumptions are invalid.


Is SYSTEM_HAS_FEATURE_MONITOR defined by default in the build process ? I assume, the compiler can 
be built without it ?


Regards,

Adriaan van Os

___
fpc-pascal maillist  -  [email protected]
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal


Re: [fpc-pascal] Corba ABI change ?

2026-02-18 Thread Adriaan van Os via fpc-pascal

Tony Whyman via fpc-pascal wrote:



Supplementing my point below, I went back and checked my notes. The 
TObject layout post 3.2 (in my copy of trunk) is now


Thanks, this is quite useful.

Regards,

Adriaan van Os

___
fpc-pascal maillist  -  [email protected]
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal


Re: [fpc-pascal] Corba ABI change ?

2026-02-18 Thread Tony Whyman via fpc-pascal
Supplementing my point below, I went back and checked my notes. The 
TObject layout post 3.2 (in my copy of trunk) is now


       TObject = class
       {$IFDEF SYSTEM_HAS_FEATURE_MONITOR}
       strict private
          _MonitorData : Pointer;
       private
          function SetMonitorData(aData,aCheckOld : Pointer) : Pointer; 
inline;

          function GetMonitorData: Pointer; inline;
       {$ENDIF}
       protected
          function GetDisposed : Boolean; inline;
          Property Disposed : Boolean Read GetDisposed;
       public

with everything before "public" having been added. The big change is the 
addition of "_MonitorData". This bumps the offset of all later fields up 
by sizeof(pointer). If you have code that makes assumptions about the 
object layout - and this very much applies to code that tries to import 
an object from C++ then your previous assumptions are invalid.


The advice I got was that for external interfaces, only the "record" 
layout is immutable between versions. In the end, I had to remove all 
the Firebird interface code that relied on the assumption that the 
Pascal object layout was the same as the C++ and replaced it with 
extended records in order to mimimise the impact on code that used the API.


There's more information about the changes to my code on github 
https://github.com/MWASoftware/fbintf/tree/main/client/3.0/firebird


On 18/02/2026 08:39, Tony Whyman via fpc-pascal wrote:


The object layout has changed post 3.2 with the addition of an
extra field. This breaks any code that makes assumptions about
this. I had a problem with the Firebird OO API due to this change
(also interfacing to C++), and had to rewrite the Firebird/IBX
interface moving away from OO to extended records.


 Original message 
From: Adriaan van Os via fpc-pascal 
Date: 17/02/2026 17:05 (GMT+00:00)
To: FPC-Pascal users discussions 
Cc: Adriaan van Os 
Subject: [fpc-pascal] Corba ABI change ?

Has there been an ABI change in the trunk compiler (compared to 
fpc-3.2.4-rc1) for CORBA interfaces
? Maybe related to "Unicode"-strings ? I have some C++ interfacing 
code that works fine with

fpc-3.2.4-rc1 but crashes with the trunk compiler.

Any hints are appreciated.

Regards,

Adriaan van Os
___
fpc-pascal maillist  - [email protected]
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

___
fpc-pascal maillist  [email protected]
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal___
fpc-pascal maillist  -  [email protected]
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal


Re: [fpc-pascal] Corba ABI change ?

2026-02-18 Thread Tony Whyman via fpc-pascal
The object layout has changed post 3.2 with the addition of an extra field. 
This breaks any code that makes assumptions about this. I had a problem with 
the Firebird OO API due to this change (also interfacing to C++), and had to 
rewrite the Firebird/IBX interface moving away from OO to extended records.
 Original message From: Adriaan van Os via fpc-pascal 
 Date: 17/02/2026  17:05  (GMT+00:00) To: 
FPC-Pascal users discussions  Cc: Adriaan van 
Os  Subject: [fpc-pascal] Corba ABI change ? Has there 
been an ABI change in the trunk compiler (compared to fpc-3.2.4-rc1) for CORBA 
interfaces ? Maybe related to "Unicode"-strings ? I have some C++ interfacing 
code that works fine with fpc-3.2.4-rc1 but crashes with the trunk compiler.Any 
hints are appreciated.Regards,Adriaan van 
Os___fpc-pascal maillist  -  
[email protected]://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal___
fpc-pascal maillist  -  [email protected]
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal


Re: [fpc-pascal] Corba ABI change ?

2026-02-18 Thread Michael Van Canneyt via fpc-pascal




On Wed, 18 Feb 2026, Adriaan van Os via fpc-pascal wrote:


Marco van de Voort via fpc-pascal wrote:


Op 17-2-2026 om 17:56 schreef Adriaan van Os via fpc-pascal:
Has there been an ABI change in the trunk compiler (compared to 
fpc-3.2.4-rc1) for CORBA interfaces ? Maybe related to "Unicode"-strings ? 
I have some C++ interfacing code that works fine with fpc-3.2.4-rc1 but 
crashes with the trunk compiler.


Please explain what you mean by "C++ interfacing code" ?

Michael.
___
fpc-pascal maillist  -  [email protected]
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal


Re: [fpc-pascal] Corba ABI change ?

2026-02-18 Thread Adriaan van Os via fpc-pascal

Marco van de Voort via fpc-pascal wrote:


Op 17-2-2026 om 17:56 schreef Adriaan van Os via fpc-pascal:
Has there been an ABI change in the trunk compiler (compared to 
fpc-3.2.4-rc1) for CORBA interfaces ? Maybe related to 
"Unicode"-strings ? I have some C++ interfacing code that works fine 
with fpc-3.2.4-rc1 but crashes with the trunk compiler.


Any hints are appreciated. 


Do you really only use the interface, or do you implicitely also use 
TObject methods or datastructures other than the pure interface?


Afaik Tobject got some methods added for D2009+ compatibility.


I see two new inline procedures, TObject.DisposeOf and TObject.CheckDisposed. I wouldn't expect 
them to change the size of the vmt, or do they ?


Regards,

Adriaan van Os

___
fpc-pascal maillist  -  [email protected]
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal


Re: [fpc-pascal] Corba ABI change ?

2026-02-17 Thread Marco van de Voort via fpc-pascal



Op 17-2-2026 om 17:56 schreef Adriaan van Os via fpc-pascal:
Has there been an ABI change in the trunk compiler (compared to 
fpc-3.2.4-rc1) for CORBA interfaces ? Maybe related to 
"Unicode"-strings ? I have some C++ interfacing code that works fine 
with fpc-3.2.4-rc1 but crashes with the trunk compiler.


Any hints are appreciated. 


Do you really only use the interface, or do you implicitely also use 
TObject methods or datastructures other than the pure interface?


Afaik Tobject got some methods added for D2009+ compatibility.

___
fpc-pascal maillist  -  [email protected]
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal