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

[David Chisnall]

On 4 Jan 2012, at 22:07, Nat! wrote:

> So I don't get it, first you say the linker can't fix it. Then you give a 
> recipe how to fix it. So what is it ? :)

I say the linker (as in a standard, existing linker) can't do it, but if we 
modified the compiler heavily to emit relocations for all selectors and we 
modified the linker massively to understand (in detail) Objective-C runtime 
data structures, then its theoretically possible.  Modifying the linker to 
support Objective-C, however, is not an acceptable solution for a system that 
needs to support multiple linkers (e.g. GNU, Solaris, Mac, Windows).

>> 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.
> 
> Well I apologise, if that was incorrect. I looked at a patch in r147493, saw 
> that NXConstantString was used in a hard coded way:
> 
> + if (StringClass.empty()) StringClass = "NXConstantString";

Yes, note the conditional.  If the string class is not explicitly stated (i.e. 
the value set in the language options is empty), then set it to 
NXConstantString, which is the default.  Otherwise, take whatever is specified. 
 You will notice that the line starts with 'if', which means that it is a 
conditional statement...

> and then I saw, that the patch was shortly reverted afterwards. So I surmised 
> some breakage and since I like to use -fconstant-string-class I get a little 
> panicky, if I figure clang is becoming incomatible.

Using -fconstant-string-class is very fragile (for constant strings to work in 
+load methods, the runtime must know what the class of constant strings is so 
that it can defer calling them until the constant string class is loaded), so 
I'd strongly recommend against it.

>>> 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.
> 
> That's OK. I probably wouldn't want to do if I was in your shoes either. I 
> need to work around it anyway for the next years, since there are too many 
> distributions out with the bug. But if I find some time, I might actually 
> take a look and try to fix the gcc ld at least.

There is no such thing as gcc ld.  There are two GNU linkers, gold and bfd ld.  
The only one that supports LTO is gold.  It should be possible to 

> dyld and ld on OS X, don't have this problem as the callback is on a true per 
> module basis.

They support an entirely different ABI.  Constant strings in the Mac ABI aren't 
fixed up in the runtime at all, they have their isa pointers set to the public 
symbol of the class.  This is precisely the same as I have just done.  The only 
difference is that I use a weak symbol because gcc does not export a public 
symbol for the classes and people complain if I break compatibility with 
GCC-compiled code.  

David