On 26 Dec 2015, at 19:15, Dmitry Moskalchuk <[email protected]> wrote: > > On 26/12/15 20:13, David Chisnall wrote: >> Thanks, >> >> I modified objc_msgSend quite recently, and as the ARM version is currently >> untested I am not surprised that it’s broken. >> >> Rereading the assembly, there was one obvious bug. Can you rerun the tests >> and see if this fixes it? If not, then there are likely some less-obvious >> bugs hiding. > > Your latest commit have fixed crash with SIGSEGV, but now it crashes > with SIGABRT, and call stack [1] is corrupted, since top level frame is > abort() itself. I'll look further and let you know about results.
Hmm, oh well. The others all took a little bit of debugging, but I thought after doing it three times I might be able to get it right. Is it possible for me to have (ssh) access to an ARM machine to run a debugger? If not, I’ll try to poke it in an emulator. It would help if you could step through the objc_msgSend function one instruction at a time and see how where it’s going wrong. Start from here: https://github.com/gnustep/libobjc2/blob/master/objc_msgSend.arm.S#L34 It should have the address of the dtable in r4 (check it does!) and should then do 1-3 loads (depending on the size of the dtable), each time getting a new SparseArray*, until it gets the slot pointer here: https://github.com/gnustep/libobjc2/blob/master/objc_msgSend.arm.S#L56 > BTW, I've bumped with problem with objc_msgSend.arm.S implementation. In > CrystaX NDK, we support several ARM ABIs, and one of them is ARMv5 with > soft-float. Compiling objc_msgSend.arm.S from '1.8.1' works fine for > ARMv5 target; but in 'master' branch, you did some modifications, adding > new ARMv7 instructions, and this break ARMv5 compilation. I know that > ARMv5 is old, but we can't just drop its support since there is still > significant amount of non-ARMv7 Android devices in the world (especially > in China). I'm not very familiar with ARM assembler, but just curious - > was switch of libobjc2 code to ARMv7 intentional or it was result of > mistake? I didn’t realise there were any ARMv5 (ARM7-ARM10) devices running Android. ARM hasn’t licensed ARMv5 cores for ages and they basically need to die. The new instructions are actually from a later ARMv6 revision, so most ARMv6 cores should support them (any that support Thumb-2). I can add a conditional path for older ARMv6 cores if required, and I think that should fix ARMv5 too. > >> Your patch [2] is applied to the long-deprecated Makefile. Is CMake >> problematic for you? > > CMake is not too problematic, but right now I'd prefer make libobjc2 > working and not spend time fighting with CMake. > >> I thought that the Android NDK came with a CMake toolchain file that makes >> cross-building easy. > > Two points here: > - No, there is no official support of CMake in Android NDK. There is > community support though, but it works in some cases, and don't work in > another; in other words, there is still no good support for Android, at > least the same good as for GNU/Linux. > - Here I'm building libobjc2 with CrystaX NDK, which is alternative fork > of Google's Android NDK. Main goal of CrystaX NDK is to provide POSIX > conforming toolchain and environment for Android native development. You > couldn't build libobjc2 with Google's Android NDK due to lack of many > underlying features in Android libc, and limitations of their toolchains. > > Taking above into account, I'd be happy to integrate libobjc2 into > CrystaX NDK as first-class citizen, i.e. include its testing into our > continuous integration procedure, ensuring there is no regressions and > they don't appear with time - neither in CrystaX NDK nor libobjc2. Also, > doing that, I'd be happy to minimize Android-specific fixes as much as > possible (ideally, completely avoid them), and this obviously means > requirement to use CMake for Android build too. This is what I > definitely will do, just bit later. > > > [1] https://gist.github.com/dmcrystax/130ccd4f4739bcdf4ab6 > > -- > Dmitry Moskalchuk > >> >> David >> >>> On 26 Dec 2015, at 17:52, Dmitry Moskalchuk <[email protected]> wrote: >>> >>> On 26/12/15 13:48, David Chisnall wrote: >>>> I think that libobjc2 should now work as well - let me know if it doesn’t. >>> David, >>> >>> I've checked out and built libobjc2 for Android. First, I've checked out >>> branch 1.8.1 [1], and applied some (mostly cosmetic) fixes [2] to make it >>> build-able for Android by CrystaX NDK. Mostly it was fixes of compiler >>> warnings, but also I've added back old Makefile, with some fixes, since >>> generating proper Makefile with cmake looks really tricky for Android - >>> cmake just don't understand that host and target systems are different and >>> generate Makefile for host system, even though I've provided proper CC, >>> CFLAGS, LDFLAGS, etc. So right now bringing back old good Makefile looks >>> better for me than fighting with cmake. >>> >>> So, having libobjc2 built for Android, I've compiled and run simple test >>> [3], just to verify that Objective-C runtime works properly. It works fine >>> on my ARM Android devices. >>> >>> Then, I've switched to 'master' branch of libobjc2 repository, and applied >>> patch [2] on top of it. It required small additions, which makes no >>> sense to specify here, just because it was trivial, but after that, when >>> libobjc2 was built from 'master' sources, that simple test started crashing >>> on my ARM Android devices. Call stack of crash [4] is bit unclear though. >>> As you can see there, it crashes somewhere inside objc_msgSend_fpret. >>> >>> As far as I see, there are many commits between 1.8.1 and master. I'm going >>> to find one, causing this crash. However, I thought it might be interesting >>> to you to get feedback on this stage too. >>> >>> >>> [1] https://github.com/gnustep/libobjc2/tree/1.8.1 >>> [2] >>> https://github.com/crystax/android-vendor-libobjc2/commit/a10757ac479704faac2b2fa32e9b0150b2a8aa8b >>> [3] >>> https://github.com/crystax/android-platform-ndk/blob/master/tests/device/crystax-test-objc-runtime/jni/test.m >>> [4] https://gist.github.com/dmcrystax/bb2c7e1c3c79e45c039d >>> >>> P.S. Please note that this is clear Objective-C code, i.e. no yet >>> Objective-C++ things involved. >>> >>> -- >>> Dmitry Moskalchuk >>> >> >> -- Sent from my Apple II >> > > -- Sent from my STANTEC-ZEBRA _______________________________________________ Gnustep-dev mailing list [email protected] https://lists.gnu.org/mailman/listinfo/gnustep-dev
