Objective-C stable ABI

Question

I'm mainly a C++ guy. As C++ lacks an official ABI I always use a COM-like approach for component designs that support more than one compiler.

Recently I came across the question whether Objective-C would be a replacement for the COM-like approach. Obviously for Objective-C to be a replacement one would need a stable ABI, therefor I'd like to know if a stable ABI for Objective-C exists (on all major OSes [OSX, GNU/Linux, Windows]) and how easy it would be to use Objective-C(++) as "glue" between components created by different compilers.

EDIT: As Nikolai Ruhe pointed out a short description of COM may be helpful. COM is essentially a "binary standard" that allows mixing binarys of different compilers (and in a variety of languages). The vehicle of COM are interfaces, which define methods (which map to C++'s virtual functions). Components implement a at least one interfaces and are distributed as DLLs. They can be located anywhere on the system (the position is specified in the Registry) and can be loaded by any COM-client via the ID of the interface they implement.

You are obviously addressing Objective-C people. It would surely be helpful if you described "the COM-like approach" a little. I have no clue what that is. — Nikolai Ruhe, Jul 27 '12 at 18:52
@NikolaiRuhe thanks, I just did that, hope it explains how COM works (on a basic level) — MFH, Jul 27 '12 at 19:01
I currently have my "own version of COM" - well sans support for languages that are not C++^^ I just thought maybe something like Objective-C++ would be a more elegant way (as anything like COM seems to be unelegant to some extend [though I hide that via wrappers in my current implementation]). It's not like my current design is not useable - I'm actually generating a whole lot of files [VTABLES, Wrappers,...] from a simple language, but that still adds the overhead of having 2 programs instead of just the compiler... — MFH, Jul 27 '12 at 19:16
Lack of C++ ABI is Windows only IIRC. Linux/Mac OS X use Itanium C++ ABI since gcc 3.4 (clang/icc is compatible with gcc) from 2004 IIRC. — Maciej Piechotka, Jul 27 '12 at 19:33
@MaciejPiechotka That's only an informal ABI as it's not specified in the C/C++ standard... Sure it's nice that GCC adopted the Itanium ABI, but that doesn't mean that you can rely on it in an uniform way... — MFH, Jul 27 '12 at 19:39
@MaciejPiechotka And, consequently, nobody relies on this ABI. Apple wraps all private C++ implementations into a public C or Objective-C API. The only exception from this rule is IOKit, where compatibility is a major headache any way (kernel, hardware). — Nikolai Ruhe, Jul 27 '12 at 20:10
@MFH In this sense there is no C ABI (there are unofficial ones like stdcall on Windows for x86, even for x86-64 there is separate between Windows and Linux). For practical purposes Linux/Mac OS X have stable (used for 10 years without any changes) ABI. — Maciej Piechotka, Jul 28 '12 at 06:20
@MaciejPiechotka Well actually there are about a dozen calling conventions (like cdecl and stdcall) in 16 and 32bit, whereas both Unix and Windows only have one in 64bit. The problem though remains as calling conventions are only part of the ABI. I for one doubt that different implementations of the Standard Library are binary compatible... — MFH, Jul 28 '12 at 08:51
@MHF: I wasn't clear. I am aware that there many calling conversion on Windows and ABI incompatibilies of standard libraries. My point was that Linux/Mac OS X have official C++ ABI you can rely on at least to certain extend (if the structure was not altered in stdlib I don't see why the stdlib would have be incompatible - I may be wrong but IIRC they are backward compatible). http://stackoverflow.com/a/4782874/49107 — Maciej Piechotka, Jul 29 '12 at 09:12
@MaciejPiechotka: the standards only specify functions/class member functions, but not how the layout of the classes should be. Therefor you can't rely on a portable implementation... Linux/OSX don't have this problem as much as Windows because there (most of the time) is only one implementation of the library on these systems (opposed to Windows, where we have a multitude of different Library implementation...). And I somewhat doubt that the implementation of the library hasn't changed in the last 10 years... — MFH, Jul 29 '12 at 12:33
@MFH: At least Itanium C++ ABI 1.83 (quick finding in Google) have whole chapter about data layout. Also the problem is not wheather the library have the same implmentation but if they broke the ABI. For example QT is example of library which tries not to break ABI as well (however they do change the library). — Maciej Piechotka, Jul 29 '12 at 20:46
@MFH: Upon rereading - you might mean inside the C++ stdlib. In such case that depends on maintainer. In general they should change SONAME in such case so you can do it to certain extend. — Maciej Piechotka, Jul 29 '12 at 21:00
@MaciejPiechotka: if you implemented std::list::size() to be O(N) [as allowed in C++98] but now import that list inside a program using C++11 you have your breaking change right there as std::list::size() is required to be O(1) now. No definition of data layout can help you there! Exactly, and that leads to not having a stable ABI in my book... — MFH, Jul 29 '12 at 21:02
@MFH: You did not show that it *did* changed but that it *might* changed (with a good reason) - I don't think it was implemented as O(N) in libstdc++. Anyway - since I don't think we agree I propose EOT. — Maciej Piechotka, Jul 30 '12 at 17:00
@MaciejPiechotka: Ok let's end this. Just for completeness sake though: std::list::size() in GCC [at least 4.1.0] is O(N) which would 100% break in C++11... — MFH, Jul 30 '12 at 17:51
@MFH: Sorry for resurrecting thread but comment on http://gcc.gnu.org/gcc-4.7/changes.html looks like the gcc is ABI compatible except minor break in 4.7.0 and 4.7.1 (fixed in 4.7.2). For more details see - http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49561 (the patch was reverted to maintain ABI compatibility). — Maciej Piechotka, Sep 14 '12 at 07:48
@MaciejPiechotka: Yep, they reverted their change back to C++98/03 mode, which means that std::list in GCC is now NOT STANDARD COMPLIANT... A problem like that wouldn't have ever happend if they hadn't exported classes directly... — MFH, Sep 14 '12 at 23:18

Nikolai Ruhe · Accepted Answer · 2012-07-27T18:46:26.247

I can only speak for Apple's implementation, as I have no experience with the GNU or other ports.

Objective-C relies on C's ABI for the most part (like function calls and memory layout of structs).

It's own ABI underwent a couple of changes in Apple's implementation, like non-fragile instance variables introduced with the "Modern Runtime", introduction of properties, faster exception handling, garbage collection, __weak support for ARC.

Some of the changes were backwards compatible, some not. But since the whole system and frameworks are provided by Apple and the changes were usually introduced with other non-compatible changes (switch to Intel, and LP64) this was without consequences to users.

Edit: One thing you should have in mind is that Objective-C does not only rely on a fixed ABI but also on a compatible runtime. That's one more headache to care about for your purpose.

How are methods (more like messages [right?]) defined on the binary level? I'm not sure if the runtime dependency would be that much of a problem, compared to the C(++) runtimes, how many are there for Objective-C(++) for the same system? — MFH, Jul 28 '12 at 17:09

Objective-C stable ABI

1 Answers1