LLVM needs to insert the Objective-C image info into the general object info
metadata. This way we don't need to store a reference to that metadata so
as to add extra data to it later (tnodeutils is never instantiated, it only
contains class methods)
Update some amigados unit record field members for AROS compatiblity.
These changes reflect the changes made in the doslib RTL (that were present in
the previous commit).
Update some amigados record structures to be 32/64-bit compatible.
These changes reflect the changes made in the doslib RTL (that were present in
the previous commit) but note that some of Unit amigados' record structures
were already up to date.
Memory sizes are expressed in IPTR/PtrUInt in order to be compatible to both
32 and 64-bit.
This changes some of Exec API call signatures and should not impact
existing code.
These changes reflect the changes made in the exec RTL (that were present in
the previous commit) but note that Unit Exec record structures were already
up to date.
See: d7df812342
Memory sizes are expressed in IPTR/PtrUInt in order to be compatible to both
32 and 64-bit.
Affects both record structures and API call signatures.
See: d7df812342
Final step that attempts to ensure that fields of particular records are
'STACKED' (stack aligned) properly for both 32 and 64 bit.
AROS introduced STACKED structure members, which are members that are padded
according to the current used stacksize which in itself is based on the target
CPU.
These structures are required to have a particular defined size in memory and
have a particular field alignment, therefor these records are always end-padded
(whether required or not) so that we are able to force the compiler to add
padding depending on the RECORDMIN setting.
Other available FPC directives and/or solutions seem currently not able to
solve that issue and we do not wish to manually check each structure to
determine if it requires end-padding or not (based on bitness) simply because
it is unmaintainable.
This change attempts to ensure that these record structures compile using the
correct memory size and field layout for both 32 and 64-bit CPU's.
The introduction of stack aligned record fields solves a lot of 64-bit related
crashes when working with native OOP such as MUI and BOOPSI.
Note: Not tested on big endian.
