NSZone Selector Missmatch

[hmelder]

The NSZone stub here has in a different signature which results in a warning at runtime when passing a gnustep-base NSZone struct to objc_allocWithZone: (@24@0:8^{_NSZone=^?^?^?^?^?^?^?Q@^{_NSZone}}16), selector has @24@0:8^{_NSZone=}16.

@davidchisnall how about changing the NSZone struct in fast_path.m to follow the same layout as in gnustep-base?

[davidchisnall]

Hmm, this is a special case of a general problem that we should probably fix:

If one compilation unit has a selector that takes a pointer to a forward-declared structure and another has one that takes a pointer to the same forward-declared structure but can see the definition, their types will not match. This is likely to be true for anything where structures are handed out as opaque types.

The right solution here is probably to have the selector hashing code skip everything between the = and } in pointers to structures (not in structures passed by value. We should hash ^{_NSZone=^?^?^?^?^?^?^?Q@^{_NSZone} and ^{_NSZone=} to the same value, but also make sure that (for example) {_NSZone=^?^?^?^?^?^?^?Q@^{_NSZone} and {_NSZone=I} hash to different values.

[hmelder]

The right solution here is probably to have the selector hashing code skip everything between the = and } in pointers to structures

Good idea. Let's merge #298 first to avoid merge conflicts later on :)

[hmelder]

The right solution here is probably to have the selector hashing code skip everything between the = and } in pointers to structures

But we also need to take care of SelectorEquals used in

libobjc2/selector_table.cc

Line 329 in a9d0313

using SelectorTable = tsl::robin_set<objc_selector*, SelectorHash, SelectorEqual>;

. Otherwise, the hash set will not consider the two selectors to be equal.

Apple just takes the address of the selector as hash, as all selectors are uniqued in __objc_selref, and does not emitting a new typed selector in a compilation unit that does not contain the implementation. Instead, an undefined stub of the form objc_msgSend$<SEL_NAME> is emitted. The actual thunk which retrieves the selector from objc_selref and calls objc_msgSend is generated by ld64.

That is not really an option for us as this requires a contract with the linker.

So I guess doing it at runtime is the best option at the expense of a more complex selector hashing and equality routine. Are we ok with that?