ld64 inserts 4096 nop instructions in __text section between symbols

Number:rdar://FB11942354 Date Originated:1/13/2023
Status:Open Resolved:
Product:Xcode Product Version:Xcode 14.2 Build version 14C18
Classification: Reproducible:yes
PLEASE PUSH A NEWER VERSION OF LD64 TO https://github.com/apple-opensource/ld64

See repro and description here: https://gist.github.com/lewurm/d08fa92c3d3193ef8f994d93ec3f7227

Please list the steps you took to reproduce the issue:
See https://gist.github.com/lewurm/d08fa92c3d3193ef8f994d93ec3f7227

What did you expect to happen?
Still working as it did in previous versions of ld64.

What actually happened?
Got a page (4k) full of nop instructions in the __text section that messes up relative addressing.



Thank you for the quick answer!

Can you elaborate on why a 4k alignment in the section header can cause the linker to insert 4k fill bytes? The symbol (Character_toUpperCaseEx_5e336fa9cb982976a8ba6aaa89c54c23324f695a) after the 4k of fill bytes at address 0x100158c40 is certainly not 4k aligned. If anything, I would expect the linker to fill in less than 4k filler bytes, so that the symbol is 4k aligned. What is the linker trying to achieve here?

Also note that this occurrence of 4k filler bytes is placed in the middle of the __text section of one input object file; I would expect the section alignment to be used when multiple sections of the same kind but from different object files are concatenated.

Furthermore, why are earlier versions of ld64 produce a working binary with the same input?

As a side note, if I bump the section alignment to 16k this sequence of filler bytes before the symbol Character_toUpperCaseEx_5e336fa9cb982976a8ba6aaa89c54c23324f695a disappears, and the emitted binary works with the latest available ld64 version.

I would really love to understand the behaviour around this.

Apple Feedback

Please know that our engineering team has determined that this issue behaves as intended based on the information provided.

The __text section in helloworld-unaligned-ptrs.o is 4KB aligned. So, when linked with other code, ld will attempt to align it, which means it will use fill bytes, in this case they are NOPs.

Please note: Reports posted here will not necessarily be seen by Apple. All problems should be submitted at bugreport.apple.com before they are posted here. Please only post information for Radars that you have filed yourself, and please do not include Apple confidential information in your posts. Thank you!