Re: undefined reference to __gnustep_objcxx_personality_v0

[David Chisnall]

On 26 Dec 2015, at 19:15, Dmitry Moskalchuk <address@hidden> 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 <address@hidden> 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