On 12 March 2014 19:36, Michel Fortin <michel.for...@michelf.ca> wrote:
> 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
> 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.
>> Some which greps for s(n)printf also show:
>> 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.
Hooking to ObjC could be done, but requires patching GCC proper so
that ObjC mangling becomes common code, not front-end specific.