Re: building libobjc2 fPIC issue and ccmake . effectiveness

[David Chisnall]

On 30 May 2020, at 22:51, Riccardo Mottola <riccardo.mottola@libero.it> wrote:
> 
> Hi David,
> 
> thanks for the help. Got a little further, but not enough.
> 
> On 5/29/20 2:00 PM, David Chisnall wrote:
>> 
>> We shouldn't be linking libsupc++.a into libobjc.so.  It sounds as if NetBSD 
>> ships a separate C++ runtime library for static linking, but not for dynamic 
>> linking.  You can work around this by explicitly setting libstdc++ as your 
>> C++ runtime library in the libobjc2 cmake config.
>> 
>> The correct fix it so tweak the C++ runtime library check in CMake so that 
>> it looks only for dynamic 
> 
> 
> I have libstdc++.so and libstdc++.a available, and libsupc++.a
> 
> so I use ccmake. and set
> 
> CXX_RUNTIME_LIB to /usr/lib/libstdc++.so
> 
> then I run (c)onfigure and (g)enerate - at that point libobjc2 fully built 
> and installed.

Great!  I am a bit confused as to why it’s finding the .a, because that should 
be looking for only libraries that end with ${CMAKE_SHARED_LIBRARY_SUFFIX}, 
which should be .so on ELF platforms.  We might need an extra check here.

> 
> I was able to reconfigure make, install base with success, but gui fails.
> 
> 
> Well, even something as easy as plparse coredumps.
> 
> crossbar$ plparse
> [1]   Segmentation fault (core dumped) plparse
> 
> 
> #0  0x00007ed0cbf45c5d in __vfprintf_unlocked_l () from /usr/lib/libc.so.12
> #1  0x00007ed0cbf43c1d in vsnprintf_l () from /usr/lib/libc.so.12
> #2  0x00007ed0cbf43d11 in snprintf () from /usr/lib/libc.so.12
> #3  0x00007ed0cd254244 in -[NSMethodSignature _initWithObjCTypes:] (
>     self=<optimized out>, _cmd=<optimized out>, t=<optimized out>)
>     at NSMethodSignature.m:539
> #4  0x00007ed0cd254391 in +[NSMethodSignature signatureWithObjCTypes:] (
>     self=<optimized out>, _cmd=<optimized out>, t=0x7ed0cd40bc4c "%d")
>     at NSMethodSignature.m:559
> #5  0x00007ed0cd2ff2da in gs_objc_msg_forward2 (
>     receiver=0x7ed0cd6f9430 <._OBJC_CLASS_NSString>,
>     sel=0x7ed0cd73e788 
> <.objc_selector_stringWithFormat:arguments:_
32
0:8
16[1{__va_list_tag=II^v^v}]24>)
>  at GSFFIInvocation.m:140
> #6  0x00007ed0ccc20639 in slowMsgLookup ()
>    from /System/Library/Libraries/libobjc.so.4.6
> #7  0x00007ed0ccc25ef0 in objc_msgSend_fpret ()
>    from /System/Library/Libraries/libobjc.so.4.6
> #8  0x00007ed0cd21f696 in +[NSException raise:format:arguments:] (
>     self=0x7ed0cd6d1d58 <._OBJC_CLASS_NSException>, _cmd=<optimized out>,
>     name=0x7ed0cd7271a8 <.objc_str_NSInvalidArgumentException>,
>     format=0x7ed0cd40bc4c, argList=0x7f7fffb6aa48) at NSException.m:1463
> #9  0x00007ed0cd21f660 in +[NSException raise:format:] (self=0x7f7fffb6a7b0,
>     _cmd=<optimized out>, name=0x7ed0cd40bc4c, format=0x7f7fffb6aa48)
>     at NSException.m:1450
> #10 0x00007ed0cd262036 in -[NSObject doesNotRecognizeSelector:] (
>     self=<optimized out>, _cmd=<optimized out>,
>     aSelector=0x7ed0cd73e788 
> <.objc_selector_stringWithFormat:arguments:_
32
0:8
16[1{__va_list_tag=II^v^v}]24>)
>  at NSObject.m:1738
> #11 0x00007ed0cd30020e in GSFFIInvocationCallback (cif=0x7ed0c6151820,
>     retp=0x7f7fffb6b310, args=0x7f7fffb6b170, user=0x7ed0c6157f88)
>     at GSFFIInvocation.m:606
> #12 0x00007ed0ca20299c in ffi_closure_unix64_inner ()
>    from /usr/pkg/lib/libffi.so.7
> #13 0x00007ed0ca202d10 in ffi_closure_unix64 () from /usr/pkg/lib/libffi.so.7
> #14 0x00007ed0cd21f696 in +[NSException raise:format:arguments:] (
>     self=0x7ed0cd6d1d58 <._OBJC_CLASS_NSException>, _cmd=<optimized out>,
>     name=0x7ed0cd7271a8 <.objc_str_NSInvalidArgumentException>,
>     format=0x7ed0cd40bc4c, argList=0x7f7fffb6aa48) at NSException.m:1463
> #15 0x00007ed0cd21f660 in +[NSException raise:format:] (self=0x7f7fffb6a7b0,
>     _cmd=<optimized out>, name=0x7ed0cd40bc4c, format=0x7f7fffb6aa48)
>     at NSException.m:1450
> #16 0x00007ed0cd262036 in -[NSObject doesNotRecognizeSelector:] (
>     self=<optimized out>, _cmd=<optimized out>,
>     aSelector=0x7ed0cd73e788 
> <.objc_selector_stringWithFormat:arguments:_
32
0:8
16[1{__va_list_tag=II^v^v}]24>)
>  at NSObject.m:1738
> #17 0x00007ed0cd30020e in GSFFIInvocationCallback (cif=0x7ed0c6151780,
>     retp=0x7f7fffb6b690, args=0x7f7fffb6b4f0, user=0x7ed0c6157f48)
>     at GSFFIInvocation.m:606
> #18 0x00007ed0ca20299c in ffi_closure_unix64_inner ()
>    from /usr/pkg/lib/libffi.so.7
> #19 0x00007ed0ca202d10 in ffi_closure_unix64 () from /usr/pkg/lib/libffi.so.7
> #20 0x00007ed0cd21f696 in +[NSException raise:format:arguments:] (
>     self=0x7ed0cd6d1d58 <._OBJC_CLASS_NSException>, _cmd=<optimized out>,
>     name=0x7ed0cd7271a8 <.objc_str_NSInvalidArgumentException>,
>     format=0x7ed0cd40bc4c, argList=0x7f7fffb6aa48) at NSException.m:1463
> #21 0x00007ed0cd21f660 in +[NSException raise:format:] (self=0x7f7fffb6a7b0,
>     _cmd=<optimized out>, name=0x7ed0cd40bc4c, format=0x7f7fffb6aa48)
>     at NSException.m:1450
> #22 0x00007ed0cd262036 in -[NSObject doesNotRecognizeSelector:] (
>     self=<optimized out>, _cmd=<optimized out>,
>     aSelector=0x7ed0cd73e788 
> <.objc_selector_stringWithFormat:arguments:_
32
0:8
16[1{__va_list_tag=II^v^v}]24>)
>  at NSObject.m:1738
> #23 0x00007ed0cd30020e in GSFFIInvocationCallback (cif=0x7ed0c61516e0,
>     retp=0x7f7fffb6ba10, args=0x7f7fffb6b870, user=0x7ed0c6157f08)
>     at GSFFIInvocation.m:606
> #24 0x00007ed0ca20299c in ffi_closure_unix64_inner ()
>    from /usr/pkg/lib/libffi.so.7
> #25 0x00007ed0ca202d10 in ffi_closure_unix64 () from /usr/pkg/lib/libffi.so.7
> #26 0x00007ed0cd21f696 in +[NSException raise:format:arguments:] (
> <etc>
> 
> 
> the stack looks corrupt. But why should it be [NSObject 
> doesNotRecognizeSelector:]?

This looks as if it is not finding the stringWithFormat:arguments: method.  
This is in -base additions.  Are you linking with BFD ld?  This looks like 
stack trace that I’d expect if Additions is not being loaded, which was the bug 
we saw with BFD LD.  Can you try using a different linker for -base?

> Then I thought... let's try "make test" in libobjc2
> 
> 98% tests passed, 4 tests failed out of 186
> 
> Total Test time (real) =  68.32 sec
> 
> The following tests FAILED:
>          25 - BlockImpTest (SEGFAULT)
>          26 - BlockImpTest_optimised (SEGFAULT)
>          27 - BlockImpTest_legacy (SEGFAULT)
>          28 - BlockImpTest_legacy_optimised (SEGFAULT)
> 
> are these expected? I suppose... not, but I wonder if they can cause the 
> issue I am seeing.

These are four variations of the same test (-O0 / -O2, ABIv1 / ABIv2).  I would 
expect the objc_msgSend tests to fail as well if it’s a problem with assembly 
paths.  Is this OpenBSD?  As I recall, OpenBSD has some restrictions on JIT’d 
code (which is what these paths are doing, effectively).  Can you look at the 
mmap / mprotect calls in block_to_imp in these tests (these tests are all in 
the Tests/ subdirectory of your build directory and the versions without the 
_optimised suffix should work well in a debugger) and see if either of them are 
failing?

David