On 2014-03-12 19:02:10 +0000, Iain Buclaw <ibuc...@gdcproject.org> said:
From my POV, I wouldn't want to support the ABI of a language that GCC itself doesn't support. So code compiled by GNU ObjC should be compatible with extern(ObjC) code generated by GDC - even if it isn't compatible with Clang ObjC. But then, I'd be surprised if it wasn't compatible.
It all comes to how you integrate the thing with GCC. My guess is that you have three choices:
1. ignore Objective-C support: don't define DMD_OBJC in the code and the compiler will complain whenever it sees extern(Objective-C)
2. translate the calls to the DMD backend creating the various sections and segments to equivalent calls for creating sections and segments in GCC
3. replace the codegen for Objective-C data structures by what's already implemented in GCC for Objective-C
This last option will support whatever ABI GCC has support for. That's probably the way to go if you want to make sure ABIs are compatible. All the Objective-C ABI DMD knows about is implemented in objc.c, so what you have to do is to rewrite objc.c to call the GCC equivalent implementation, probably getting rid of most of the code in there.
NeXT: NSConstantString objc_getClass objc_getMetaClass objc_msgSend objc_msgSendSuper GNU: NXConstantString objc_get_class objc_get_meta_class objc_msg_lookup objc_msg_lookup_super Some which greps for s(n)printf also show: NeXT: ".objc_class_name_%s" ".objc_category_name_%s_%s" GNU: "__objc_class_name_%s" "__objc_category_name_%s_%s" Most others look the same? Maybe you'll be able to find out more with this information.
My understanding is that the differences are pretty trivial. But regardless, we probably don't have to care about them if you can hook directly to the GCC Objective-C codegen.
-- Michel Fortin michel.for...@michelf.ca http://michelf.ca
