Re: libobjc2-clang

[Wolfgang Lux]

> Am 28.06.2020 um 21:21 schrieb Wolfgang Lux <wolfgang.lux@gmail.com>:
> 
> 
> 
>> Am 18.06.2020 um 17:21 schrieb Riccardo Mottola <riccardo.mottola@libero.it>:
>> 
>> Hi David,
>> 
>> David Chisnall wrote:
>>> 
>>>> On 18 Jun 2020, at 12:52, Riccardo Mottola <riccardo.mottola@libero.it> 
>>>> wrote:
>>>> 
>>>> you guessed correctly and the protocol is also a very common one, NSCopying
>>> So, part of the question is whether this is the first time we’re seeing 
>>> this or not.  Can you stick a watchpoint on the isa pointer and restart it, 
>>> see if it’s modified before here?
>> 
>> as simple as this?
>> (gdb) watch aProto->isa
>> Hardware watchpoint 4: aProto->isa
>> 
>> I rerun the program but it fails through to the crash - so it appears that 
>> it does not het changed, or I did not set it correct.
>> 
>> 
>>> That’s very odd.  Here’s the definition of the enum:
>>> 
>>> https://github.com/gnustep/libobjc2/blob/369c84db35a6a1e94f8a4689a695fabdac056166/protocol.h#L26
>>> 
>>> The isa pointer for each protocol is initially set to one of those enum 
>>> values (2, 3, or 4) by the compiler and is then set to a proper Objective-C 
>>> class.  It should never end up 0.  It’s possible that something has 
>>> corrupted memory or that we’ve just read the low 32 bits this has been set 
>>> to a 64-bit address that happens to have nothing in the low 32 bits, but it 
>>> seems quite unlikely.
>>> 
>> 
>> I see, this is very strange. What is "really" strange is that that this is 
>> amd64 bit architecture and a known compiler, the same code works on FreeBSD 
>> (and Linux IIRC).
>> NetBSD would make the difference? or that this is "genuine AMD" and not 
>> intel? would be very strange.
>> 
>>> 
>>>> I confirm OLDABI_COMPAT is on. I did not touch it. LEGACY_COMPAT is off.
>>>> 
>>>> I only changed the linker option and then the build type.
>>>> 
>>>> Further question: this is a from-scratch install, all compiled with the 
>>>> same version of clang, can I assume that all libraryes have the same ABI 
>>>> or not? maybe there is a makefile issue somewhere?
>>> Should be.  You can see if __objc_exec_class is called - that’s the entry 
>>> point used by old ABI code.
>> 
>> (gdb) b __obj_exec_class
>> Function "__obj_exec_class" not defined.
> 
> The correct name would have been __objc_exec_class.
> 
>> Apparently it is not even defined, but this is strange, since I compiled 
>> with OLDABI_COMPAT:
>> 
>> I tried being more explicit:
>> (gdb) b loader.c:328
>> Breakpoint 3 at 0x72b92fe1859f: file 
>> /home/multix/code/gnustep-vcs/libobjc2/loader.c, line 330.
>> 
>> and re-run the program, it does not get into that function, so we can assume 
>> it is new code.
> 
> Anyway, I was able to reproduce this issue on NetBSD 9.
> First of all getting the configuration right seems to be a royal PITA. So 
> what I did was:
> 
> 1. Configure libobjc2 with cmake -DCMAKE_C_COMPILER=clang 
> -DCMAKE_CXX_COMPILER=clang++ -DCXX_RUNTIME_LIB=/usr/lib/libstdc++.so 
> -DCMAKE_BUILD_TYPE=RelWithDebInfo
> The CXX_RUNTIME_LIB option is necessary because cmake by default wants to use 
> /usr/lib/libsupc++.a (as Riccardo already noticed earlier).
> The CMAKE_BUILD_TYPE is only necessary to debug the runtime itself (but that 
> was of course necessary in this case).
> 
> 2. Configure gnustep-make with ./configure CC=clang CXX=clang 
> --with-layout=gnustep --with-library-combo=ng
> The --with-library-combo option (yes, ng is sufficient, it's an alias for 
> ng-gnu-gnu) is necessary to detect the new runtime system. ISTR, that this 
> would be detected automatically when configuring with clang, but apparently 
> it didn't work for me on NetBSD.
> 
> 3. Install GNU binutils via pkgin, because the NetBSD loader seems to 
> generate invalid objects files for subprojects, too.
> 
> 4. Build gnustep-base and gnustep-back with the command
>  env AUXILIARY_LDFLAGS=-fuse-ld=/usr/pkg/gnu/bin/ld.gold make
> to make clang use gold instead of the standard linker. You can use
>  AUXILIARY_LDFLAGS=-fuse-ld=/usr/pkg/gnu/bin/ld.gold make
> instead if you're not using a csh as I do.
> 
> This was at least enough to get Ink compiled and running.
> 
> I'm still facing problems with my favorite toy project StepTalk because 
> apparently it doesn't get the compilation flags right and misses out the 
> dependent libraries on at least the StepTalk framework itself. In effect that 
> means that the framework can be initialized before gnustep-base and hence all 
> protocols have their isa pointer set to 0, which obviously causes problems 
> later.

And another problem I'm facing is that exceptions aren't caught but rather 
crash the program. For instance, given the simple test program
  #import <Foundation/Foundation.h>

  int
  main()
  {
    @autoreleasepool {
      @try {
        [NSException raise: @"Test" format: @"Test"];
      }
      @catch (NSException *e) {
        NSLog(@"Caught exception %@", e);
      }
    }
    return 0;
  }
I would expect a message 'Caught exception Test' in the shell, but on NetBSD 
the program simply runs into the uncaught exception handler and then aborts:
(gdb) bt
#0  0x000074bd057678aa in _lwp_kill () from /usr/lib/libc.so.12
#1  0x000074bd0576715a in abort () from /usr/lib/libc.so.12
#2  0x000074bd06a28411 in _terminate () at NSException.m:1370
#3  0x000074bd06a283cd in _NSFoundationUncaughtExceptionHandler (
    exception=0x74bd06708ea8) at NSException.m:1395
#4  0x000074bd06a26ec6 in callUncaughtHandler (value=0x74bd06708ea8)
    at NSException.m:1415
#5  0x000074bd064191f1 in objc_exception_throw (object=0x74bd06708ea8)
    at /home/wlux/src/GNUstep/libobjc2/eh_personality.c:243
#6  0x000074bd06a27aff in -[NSException raise] (self=0x74bd06708ea8, 
    _cmd=0x74bd06dbe078 <objc_selector_raise_v160:8>) at NSException.m:1586
#7  0x000074bd06a2713f in +[NSException raise:format:arguments:] (
    self=0x74bd06d52b18 <._OBJC_CLASS_NSException>, 
    _cmd=0x74bd06dc08d8 
<.objc_selector_raise:format:arguments:_v400:81624[1{__va_list_tag=II^v^v}]32>, 
name=0xa9979f4000000024, format=0xa9979f4000000024, 
    argList=0x7f7fff19e870) at NSException.m:1465
#8  0x000074bd06a270b7 in +[NSException raise:format:] (
    self=0x74bd06d52b18 <._OBJC_CLASS_NSException>, 
    _cmd=0x6014a0 <objc_selector_raise:format:_v320:81624>, 
    name=0xa9979f4000000024, format=0xa9979f4000000024) at NSException.m:1450
#9  0x0000000000400eb1 in gnustep_base_user_main () at testCatch.m:8
#10 0x000074bd06abd6da in main (argc=1, argv=0x7f7fff19e948, 
    env=0x7f7fff19e958) at NSProcessInfo.m:1008
#11 0x0000000000400dad in ___start ()
#12 0x00007f7f5460e918 in ?? () from /libexec/ld.elf_so
#13 0x0000000000000001 in ?? ()
#14 0x00007f7fff19efb8 in ?? ()
#15 0x0000000000000000 in ?? ()