[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: libobjc2-clang
From: |
Wolfgang Lux |
Subject: |
Re: libobjc2-clang |
Date: |
Sun, 28 Jun 2020 21:55:07 +0200 |
> 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 ?? ()
- Re: libobjc2-clang, (continued)
- Re: libobjc2-clang, David Chisnall, 2020/06/11
- Re: libobjc2-clang, Riccardo Mottola, 2020/06/12
- Re: libobjc2-clang, Wolfgang Lux, 2020/06/12
- Re: libobjc2-clang, Riccardo Mottola, 2020/06/17
- Re: libobjc2-clang, Wolfgang Lux, 2020/06/17
- Re: libobjc2-clang, David Chisnall, 2020/06/18
- Re: libobjc2-clang, Riccardo Mottola, 2020/06/18
- Re: libobjc2-clang, David Chisnall, 2020/06/18
- Re: libobjc2-clang, Riccardo Mottola, 2020/06/18
- Re: libobjc2-clang, Wolfgang Lux, 2020/06/28
- Re: libobjc2-clang,
Wolfgang Lux <=
- Re: libobjc2-clang, Riccardo Mottola, 2020/06/29
- Re: libobjc2-clang, Wolfgang Lux, 2020/06/30
- Re: libobjc2-clang, Riccardo Mottola, 2020/06/30