Re: Multiple _OBJC_Module in the same shared library/framework, not so good

[David Chisnall]

On 4 Jan 2012, at 10:36, Nat! wrote:

> 
> Am 04.01.2012 um 00:25 schrieb David Chisnall:
> 
>> Hi Nat,
>> 
> Hi David,
> 
> 
>> This is, unfortunately, a limitation imposed on us by the old GCC ABI.
> 
> That reads to me as "inevitable", which I can't agree with, due to this being 
> IMO a linker issue.

It's not a linker issue, because there's nothing a linker can do to fix it.  
Merging objc_module structures requires understanding them, which is incredibly 
nontrivial - for example, selector references in Objective-C refer to fixed 
offsets within a selector list, and the module contains a pointer to the start 
of this list so you'd have to fix up the 

>> With the non-fragile ABI (and clang's transitional ABI), classes all export 
>> a public symbol, so it is possible for us to initialise the isa pointer as a 
>> weak reference to the public symbol for the NSConstantString class so that 
>> the fixup in the runtime becomes redundant.  This is done in clang r147493 
>> and your test case now passes for me.  It should work as long as 
>> GNUstep-base is compiled with clang.  If it was not, then the weak symbol 
>> will be resolved to null at link time and you will see the same crash.
> 
> Seems to have been reverted already.

Ugh, someone reverted it because the test failed, even though the problem was 
the test, not the code.  It's now back and the test is fixed.

> The quick fix to hardcode NXConstantString is really bad, because it breaks 
> -fconstant-string-class.

Oddly enough, not being an idiot, I tested it with -fconstant-string-class, and 
did not hard-code NXConstantString, unless that is omitted.  I'd like to change 
the default when -fconstant-string-class is omitted to NSConstantString, but 
last time I did that it broke GNUstep's configure script.

The fix was not to hardcode NXConstantString, it was (as I said) to initialise 
the strings isa pointers with a weak reference to the string class 
(NXConstantString or whatever is specified on the command line) - exactly the 
same constant string class that is specified by name at the start of the list.  

> Anway, I still think the proper solution would be to improve the linker to 
> coalesce multiple _OBJC_Module into one. This would have also the side 
> benefits of a bit faster startup time and a bit smaller object files. 

Sure, if you want to completely rewrite the linker on every possible platform 
then be my guest.  Apple can do this, because they only have one linker to 
worry about.  I do, however, plan on implementing objc_module merging as a 
link-time optimisation pass at some point.  I'm not currently motivated to do 
this because the only linker that supports LTO on non-Apple platforms is GPLv3, 
but this should change in the next couple of months.

> I hope the gcc compiler isn't abandoned now by GNU/GNUstep ?

No compiler is developed as part of GNUstep.  Nicola Pero contributes to 
Objective-C support in GCC, I contribute to Clang.  Currently, however, Clang 
is at feature-parity on Apple and non-Apple platforms, while GCC just about 
supports Objective-C from the OS X 10.4 era.  If you want to use the 
non-fragile ABI, fast message dispatch, blocks, or automatic reference 
counting, for example, then clang is currently your only choice.  For me, going 
back to using Objective-C without ARC is now quite painful.

The decision by the FSF to make GCC GPLv3 has also made it unacceptable to some 
places downstream.  FreeBSD, for example, is in the process of removing GCC 
(currently GCC 4.2.1, the last GPLv2 version) from the base system, in favour 
of clang.  I believe OpenBSD will be replacing GCC 4.2.1 with PCC (which has no 
Objective-C support) and is now using clang to compile the packages.

You are, of course, free to choose whatever compiler you want, but be aware 
that gcc is going to have problems with any code written for Apple platforms in 
the last few years.

> If fixes are now done only in clang and not in gcc, that would implicate it 
> to me.

You have an aversion to using a permissively licensed compiler with good 
language support?

David

--
This email complies with ISO 3103