Re: libobjc2-clang

[Wolfgang Lux]

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

Wolfgang