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. _______________________________________________ Discuss-gnustep mailing list [email protected] https://lists.gnu.org/mailman/listinfo/discuss-gnustep
