[SOLVED] How to hide "pointer not aligned in 'xyz'" in Messages window

[Hansaplast]

Running Lazarus 4.99 (rev main_4_99-3421-g449b0a887c) FPC 3.3.1 x86_64-darwin-cocoa, but this is not specific for this version, and am getting tons (37000+) warnings that pointers are not aligned.
This probably has a good reason since I build with the latest Cocoa SDK.

That aside, how can I hide these messages in the "Messages" window?

Example:

Code: Pascal  [Select][+][-]

1. Warning: ld: warning: pointer not aligned in '_RTTI_$COCOAGDIOBJECTS_$$_TCOCOASTATDASHES'+0x1A (/Users/hans/lazarus/lazarus/lcl/units/x86_64-darwin/cocoa/cocoagdiobjects.o)
2. Warning: ld: warning: pointer not aligned in '_RTTI_$COCOAGDIOBJECTS_$$_TCOCOASTATDASHES'+0x2A (/Users/hans/lazarus/lazarus/lcl/units/x86_64-darwin/cocoa/cocoagdiobjects.o)
3. Warning: ld: warning: pointer not aligned in '_RTTI_$COCOAGDIOBJECTS_$$_TCOCOASTATDASHES'+0x3A (/Users/hans/lazarus/lazarus/lcl/units/x86_64-darwin/cocoa/cocoagdiobjects.o)
4. Warning: ld: warning: pointer not aligned in '_RTTI_$COCOAGDIOBJECTS_$$_PCOCOASTATDASHES'+0x1A (/Users/hans/lazarus/lazarus/lcl/units/x86_64-darwin/cocoa/cocoagdiobjects.o)
5. Warning: ld: warning: pointer not aligned in '_RTTI_$COCOAGDIOBJECTS_$$_TCOCOADASHES'+0x1E (/Users/hans/lazarus/lazarus/lcl/units/x86_64-darwin/cocoa/cocoagdiobjects.o)
6. Warning: ld: warning: pointer not aligned in '_INIT_$COCOAGDIOBJECTS_$$_TCOCOAPEN'+0x33 (/Users/hans/lazarus/lazarus/lcl/units/x86_64-darwin/cocoa/cocoagdiobjects.o)
7. Warning: ld: warning: pointer not aligned in '_RTTI_$COCOAGDIOBJECTS_$$_TCOCOAPEN'+0x13 (/Users/hans/lazarus/lazarus/lcl/units/x86_64-darwin/cocoa/cocoagdiobjects.o)

[Thaddy]

You can hide them with the proper alignment settings in the code: in this case 16 or 32. That will also fix them.
To be sure, both {$align 16} and {$codealign proc=16}.

This is not a linker issue, but a code issue. The linker merely detects the alignment is wrong. Which means your code is either inefficient or won't work.
On Apple M<x> hardware (aarch64) it is merely inefficient. On Apple Intel it would likely crash.

The default proc alignment for fpc is sizeof(pointer) which on Apple M<x> is 8 I believe.

See the manual:
https://www.freepascal.org/docs-html/current/prog/progsu9.html#x16-150001.2.9

[Hansaplast]

Thanks Thaddy for the insight! It is very helpful, and ... learning something new every day 😉

I tried adding this to the compiler options, but it didn't make a difference.

Code: Pascal  [Select][+][-]

1. -OaPROC=32
2. -OaJUMP=32

(also tried 16 instead of 32)

It affects all unit (FPC, Lazarus, components and my own units), so adding the {$align} option to each and every unit seems a little much. 😉
Maybe I should do a rebuild in FPCUpDeluxe with these options?
Or would these compiler options not help?

FYI: I'm compiling with an x86_64 compiler on a Apple Silicon Mac. The applications run just fine though, even when I cross compile to ARM.

[marcov]

The warnings you show are about code alignement, not data alignment; look up $packrecords, or simply remove old "packed" before record on non 32-bit x86.

[Hansaplast]

Thanks Marcov for chiming in. 😊

I do not use $packrecords, and ... it affects literally everything that is being compiled (FPC units, Lazarus units, and my own units).
I'm 100% sure this is triggered by me using "-WM15.0" to make sure the 15.0 SDK is being used.

Is there any way to mute linker messages (even though that is not the best idea)?

[PascalDragon]

The warnings you show are about code alignement, not data alignment; look up $packrecords, or simply remove old "packed" before record on non 32-bit x86.

That will all not help. Look at the warnings, these are about RTTI and INIT records of the RTTI, so they are generated by the compiler, because on x86 platforms the RTTI data is generated in a packed format and thus pointers can be on odd addresses. The question is whether that warning of ld can be suppressed through a parameter then can then be forwarded by FPC to ld using the -k parameter.

This is not a linker issue, but a code issue. The linker merely detects the alignment is wrong. Which means your code is either inefficient or won't work.
On Apple M<x> hardware (aarch64) it is merely inefficient. On Apple Intel it would likely crash.

On Intel misalignment is merely inefficient, there won't be any crashes. It was the ARM platforms that originally required proper alignment (which is why the RTTI data on non-x86 platforms is generated in an aligned way) and Aarch64 by default also operates in a way that non-aligned data accesses lead to exceptions, most operating systems disable that however.

[Hansaplast]

The question is whether that warning of ld can be suppressed through a parameter then can then be forwarded by FPC to ld using the -k parameter.

Yep, that is what I was looking for! 😊
Thanks for this, you pointed me in the right direction.

I did find the "ld" option "-unaligned_pointers suppress"

Man page:

Code: Bash  [Select][+][-]

1. -unaligned_pointers treatment
2. Specifies how unaligned pointers in __DATA segments should be handled. Options are: 'warning', 'error', or 'suppress'.  
3. The default for arm64e is 'error' and for all other architectures it is 'suppress'.

Adding it to the linker option "Pass options to linker with -k" does the trick ("-w" worked as well).

[PascalDragon]

Man page:

Code: Bash  [Select][+][-]

1. -unaligned_pointers treatment
2. Specifies how unaligned pointers in __DATA segments should be handled. Options are: 'warning', 'error', or 'suppress'.  
3. The default for arm64e is 'error' and for all other architectures it is 'suppress'.

I wonder why it's triggering a warning in the first place then if it's supposed to be suppress for non-arm64e platforms. 🤔

[Hansaplast]

Seems these errors are related to the SDK version(s) I'm using.

I'm using a newer SDK version (15.0 by using the "-WM15.0" directive) for this project.
But I'm seeing the same warnings when compiling with SDK 26.2.
Building with both SDK's works just fine otherwise though.

Note: When building FPC / IDE with the latest SDK (26.2) certain issues in the IDE disappear (like selecting tabs on a TPageControl during designtime suddenly works).

When not selecting a specific SDK, this warning does not appear.

[Thaddy]

When not selecting a specific SDK, this warning does not appear.

Can you confirm success in that case? That is important to me for future support:
Then I don't have to fire up the toy, which I will do anyway, but frankly, I don't like to work with the M4, especially the included software. It is certainly not my main machine.

[Hansaplast]

I can confirm that when not selecting a specific [newer] SDK, these warnings do not appear - I had tested it to make 100% sure before posting my previous reply 😊

[Thaddy]

Thank you! (btw I am not bashing it is just an opinion, probably related to my daughter's insistance on everything Apple: It might be a permanent wallet question: IPhone 17's do not come cheap...but the M4 mini was a lot cheaper... so now I have the worst of both worlds...)

[Hansaplast]

Oh no worries - not a fan of Tahoe myself either. 😉
Not sure why Apple is doing this (my guess: making macOS and iOS grow closer/similar), but in the end nobody asked for this.

[Thaddy]

Off topic: is an IPhone 17 really a must have fashion requirement not to loose respect from your peers? (The 17 year old monster says so, if communicative at all, I already fell into her trap, so she has it, but only thanks to her mother, not me...My wallet looks like /dev/null )

[Hansaplast]

Haha, well I would say "no", but over here an iPhone feels like a status symbol for the younger generation(s) 😉
My nephews would say the same as you 17 year old monster haha.
Personally: I wouldn't even see the difference between an iPhone 15 or 17 hahah. 😉

On that note: nothing wrong with Android devices either.
Just a different ecosystem and I do like the Apple ecosystem, but to each their own of course.