Previously, we treated it as a regular ConcatInputSection. However, ld64
actually parses its contents and uses that to synthesize a single image
info struct, generating one 8-byte section instead of `8 * number of
object files with ObjC code`.
I'm not entirely sure what impact this section has on the runtime, so I
just tried to follow ld64's semantics as closely as possible in this
diff. My main motivation though was to reduce binary size.
No significant perf change on chromium_framework on my 16-core Mac Pro:
base diff difference (95% CI) sys_time 1.764 ± 0.062 1.748 ± 0.032 [ -2.4% .. +0.5%] user_time 5.112 ± 0.104 5.106 ± 0.046 [ -0.9% .. +0.7%] wall_time 6.111 ± 0.184 6.085 ± 0.076 [ -1.6% .. +0.8%] samples 30 32