libobjc2 AArch64

[Jordan Schidlowsky]

Hey David, Just moving to new thread...

> Is it fixed in the latest head (including my fix from yesterday)?  If you’re 
> compiling in a release build, that would explain it.  Note that this code 
> path should only have been an issue using the 1.x ABI.  If you’re compiling 
> with -fobjc-runtime=gnustep-2.0 (which should give you 5-10% smaller 
> binaries, so might be a good idea on Android…) then you won’t have hit that 
> bug.

Sorry I should have clarified...  But we're using -fobjc-runtime=gnustep-1.9 
and obviously the latest 1.9 runtime (with a few mods).   We swapped out the 
hash implementation for khash ( Not because of performance, but when we ran 
things with address-sanitizer on device we got some odd corruption faults.  Not 
sure if this was actually a hash table bug, or just something different or 
weird with android's libc).  We also found some odd memory errors in the ARC 
weak reference table when we ran things with the sanitizer, so we made a few 
changes there as well.   Again not really sure if these issues were specific to 
android or not.  

> It would be great to see test results for vfp / neon.  Looking at the 
> objc_msgSend code, I *think* we may be missing .save directives for the 
> floating-point register saves, so hitting the C path may cause corruption in 
> the case where the +initialize method throws an exception.  There’s a test 
> for this case in the test suite, but I don’t know if it’s ever been run on a 
> hard-float ARM platform…

I'm almost sure that something is being smashed when we enable NEON (or hard 
float ABI for that matter) on armv7-a.   Have no issues when using soft float 
ABI, and vfpv3-d16 instead of neon.   I've tweaked objc_msgSend here and there 
trying a different ABI target and could never get it correctly working.  Almost 
all the android devices we're targeting now are AArch64, so we're pretty 
content with sticking with whats currently working and focussing on getting 
libobjc2 and base working on AArch64.  Google has put in place a hard deadline 
of August 2019, that it won't accept apps to the Play Store unless they provide 
native arm64-v8a libraries.  

> 
> Are you still using the ARMv5 stuff?  That’s there for some Chinese Android 
> devices, but I don’t know if anyone still cares about it.

Definitely not.   Google's requirement on the Play store to move to armv7-a was 
quite a long time ago now...  There is a lot of different Android distribution 
channels in China, but as far as I know armv7-a is probably a pretty standard 
floor. 

> 
> --- a/objc_msgSend.aarch64.S
> +++ b/objc_msgSend.aarch64.S
> @@ -79,7 +79,8 @@
>        ldp    \receiver, x8, [sp], #16
>        br     x9
> 6:
> -       adr    x10, SmallObjectClasses
> +       adrp    x10, :got:SmallObjectClasses
> +       ldr     x10, [x10, :got_lo12:SmallObjectClasses]
>        ldr    x9, [x10, x9, lsl #3]
>        b      1b
>        .cfi_endproc

I will try that.  (I suspect it will).  We will still have a relocation in the 
32bit objc_msgSend.arm.S but ya I suspect that would remove the relocation for 
aarch64.

> 
> I don’t have an AArch64 environment that I can test very easily at the 
> moment, but I believe this should fix it.  Patches very welcome!

Heh....  I hear you.  We probably have about a hundred different Android test 
devices at our office, so cross compiling is our workflow.  After we ship this 
new game, I maybe can tackle the AArch64 builds on the new 2.0 runtime, as 
we're not really tied to any runtime version for any reason.  But ya, I think 
my starting point will probably to get the actual test suite running on device.