FastPathAlloc tests failing on Android NDK r27

[triplef]

These tests were being skipped up to test run #385 but have been failing since #386 where the default NDK on the GitHub runners seem to have been updated from r25 with Clang 14 to r27 with Clang 18.

FAILED (134): FastPathAlloc (0s)
Output:
[ShouldAlloc alloc] called
[ShouldAllocWithZone allocWithZone:] called
[ShouldInit init] called
[ShouldInit2 alloc] called
[ShouldInit2 init] called
[NoAlloc alloc] called
/home/runner/work/libobjc2/libobjc2/Test/FastPathAlloc.m:114: int main(void): assertion "!called" failed

Google ships modified Clang builds with the NDK, so maybe it’s something specific to these builds. The NDK releases page has the upstream Clang revisions they are based on.

[hmelder]

This is only happening with the r27 toolchain. r26 and r28 are unaffected.

[hmelder]

Turns out that clang in r27 emits the v1 ABI

Snippet of FastPathAlloc main (r27)

[...]
    4254: f0000008     	adrp	x8, 0x7000 <._OBJC_CLASS_ShouldAlloc+0x8>
    4258: f90013e8     	str	x8, [sp, #0x20]
    425c: 392c611f     	strb	wzr, [x8, #0xb18]
    4260: d503201f     	nop
    4264: 1001bbe8     	adr	x8, 0x79e0 <._OBJC_REF_CLASS_NoInit2>
    4268: f9400108     	ldr	x8, [x8]
    426c: d10183a0     	sub	x0, x29, #0x60
    4270: f81a03a8     	stur	x8, [x29, #-0x60]
    4274: d503201f     	nop
    4278: 1001b441     	adr	x1, 0x7900 <.objc_selector_alloc_160:8>
    427c: f90007e1     	str	x1, [sp, #0x8]
    4280: aa1f03e2     	mov	x2, xzr
    4284: f9000be2     	str	x2, [sp, #0x10]
    4288: 9400003e     	bl	0x4380 <objc_msg_lookup_sender@plt>
    428c: f94007e1     	ldr	x1, [sp, #0x8]
    4290: f9401008     	ldr	x8, [x0, #0x20]
    4294: f85a03a0     	ldur	x0, [x29, #-0x60]
    4298: d63f0100     	blr	x8
    429c: f9400be2     	ldr	x2, [sp, #0x10]
[...]

r28:

[...]
    70b4: 1004bbe8     	adr	x8, 0x10830 <._OBJC_REF_CLASS_NoInit>
    70b8: f9400100     	ldr	x0, [x8]
    70bc: 9400007d     	bl	0x72b0 <objc_alloc_init@plt>
    70c0: f9400be8     	ldr	x8, [sp, #0x10]
    70c4: 3965c108     	ldrb	w8, [x8, #0x970]
    70c8: 35000068     	cbnz	w8, 0x70d4 <main+0x210>
    70cc: 14000001     	b	0x70d0 <main+0x20c>
    70d0: 14000009     	b	0x70f4 <main+0x230>
    70d4: f0ffffc0     	adrp	x0, 0x2000 <stderr+0x2000>
    70d8: 91032c00     	add	x0, x0, #0xcb
    70dc: 52800f41     	mov	w1, #0x7a               // =122
    70e0: f0ffffc2     	adrp	x2, 0x2000 <stderr+0x2000>
    70e4: 9106d042     	add	x2, x2, #0x1b4
    70e8: f0ffffc3     	adrp	x3, 0x2000 <stderr+0x2000>
    70ec: 91068463     	add	x3, x3, #0x1a1
    70f0: 94000068     	bl	0x7290 <__assert2@plt>
    70f4: b0000048     	adrp	x8, 0x10000 <._OBJC_CLASS_ShouldAllocWithZone+0x70>
    70f8: f90007e8     	str	x8, [sp, #0x8]
    70fc: 3925c11f     	strb	wzr, [x8, #0x970]
    7100: d503201f     	nop
    7104: 1004b9a8     	adr	x8, 0x10838 <._OBJC_REF_CLASS_NoInit2>
    7108: f9400100     	ldr	x0, [x8]
    710c: 94000069     	bl	0x72b0 <objc_alloc_init@plt>
    7110: f94007e8     	ldr	x8, [sp, #0x8]
    7114: 3965c108     	ldrb	w8, [x8, #0x970]
    7118: 35000068     	cbnz	w8, 0x7124 <main+0x260>
    711c: 14000001     	b	0x7120 <main+0x25c>
    7120: 14000009     	b	0x7144 <main+0x280>
    7124: f0ffffc0     	adrp	x0, 0x2000 <stderr+0x2000>
    7128: 91032c00     	add	x0, x0, #0xcb
    712c: 52800fc1     	mov	w1, #0x7e               // =126
    7130: f0ffffc2     	adrp	x2, 0x2000 <stderr+0x2000>
    7134: 9106d042     	add	x2, x2, #0x1b4
    7138: f0ffffc3     	adrp	x3, 0x2000 <stderr+0x2000>
    713c: 91068463     	add	x3, x3, #0x1a1
    7140: 94000054     	bl	0x7290 <__assert2@plt>
    7144: b85fc3a0     	ldur	w0, [x29, #-0x4]
    7148: a9447bfd     	ldp	x29, x30, [sp, #0x40]
    714c: 910143ff     	add	sp, sp, #0x50
    7150: d65f03c0     	ret
[...]

[hmelder]

Turns out that Google freezed llvm mid-january right before the merge of llvm/llvm-project#76694 and llvm/llvm-project#88671 (identifies as 18.0.3). On aarch64 this means that r27 still emits the legacy dispatch code and is generally not aware of the fast-path alloc/init optimisations.

However we only check for 18.x and not > 18.1.x in CMakeLists.txt

[davidchisnall]

Hopefully we can just bump the check?