Re: undefined reference to __gnustep_objcxx_personality_v0

[Dmitry Moskalchuk]

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.

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?

> 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
>

signature.asc
Description: OpenPGP digital signature