I'm continuing the work done by Michel Fortin of adding support for "extern (Objective-C)" to D. I've already merged the latest changes of DMD and fixed some minor issues. The problem I now have is when linking some code that calls an Objective-C method. The object file is supposed to contain a section __message_refs, in the __OBJC segment. This section contains pointers to C strings, which contain the names of the Objective-C selectors (methods). The C strings are stored in the __cstring __TEXT section and segment. As far as I can see the these sections looks to have the correct flags and contents.

The problem is I'm getting an assertion in the linker:

http://www.opensource.apple.com/source/ld64/ld64-134.9/src/ld/parsers/macho_relocatable_file.cpp

Line 5024, in Objc1ClassReferences<A>::targetCString. I'm pretty sure that the value of "fit->binding" should be "ld::Fixup::bindingByContentBound" but instead it is "ld::Fixup::bindingDirectlyBound". The definition of these enums are located here:

http://www.opensource.apple.com/source/ld64/ld64-134.9/src/ld/ld.hpp

Line 358, in Fixup::TargetBinding.

This is the result of "dumpobj" on the D object file that fails to link:

http://pastebin.com/uPNZ8DpA

This is the dump of a corresponding Objective-C object file:

http://pastebin.com/NjbRRdZM

The following is a dump of Michel's original pre compiled alpha release from 2011 that does not have this problem:

http://pastebin.com/rjjT1LBU

-- 
/Jacob Carlborg

_______________________________________________
dmd-internals mailing list
dmd-internals@puremagic.com
http://lists.puremagic.com/mailman/listinfo/dmd-internals

I note that your file has L_OBJC_METH_VAR_NAME_0, L_OBJC_METH_VAR_NAME_2, L_OBJC_METH_VAR_NAME_4 (incrementing by two each time) while my old alpha had L_OBJC_METH_VAR_NAME_0, L_OBJC_METH_VAR_NAME_1, L_OBJC_METH_VAR_NAME_2, incrementing by one... I don't think this is the problem though.

Which D file are you using to make this object file?

-- 
Michel Fortin
michel.fortin@michelf.ca
http://michelf.ca/

_______________________________________________
dmd-internals mailing list
dmd-internals@puremagic.com
http://lists.puremagic.com/mailman/listinfo/dmd-internals

On 12 maj 2013, at 17:53, Michel Fortin <michel.fortin@michelf.ca> wrote:

> I note that your file has L_OBJC_METH_VAR_NAME_0, L_OBJC_METH_VAR_NAME_2, L_OBJC_METH_VAR_NAME_4 (incrementing by two each time) while my old alpha had L_OBJC_METH_VAR_NAME_0, L_OBJC_METH_VAR_NAME_1, L_OBJC_METH_VAR_NAME_2, incrementing by one... I don't think this is the problem though.

I'm pretty sure it's the opposite way. Example, on this line you're incrementing "classnamecount":

https://github.com/michelf/dmd/blob/d-objc/src/objc.c#L378

Then again on line 381.

> Which D file are you using to make this object file?

This one:

https://github.com/jacob-carlborg/dmd/blob/objc_merge/test_objc/runnable/objc_call.d

-- 
/Jacob Carlborg

_______________________________________________
dmd-internals mailing list
dmd-internals@puremagic.com
http://lists.puremagic.com/mailman/listinfo/dmd-internals

Le 12-mai-2013 à 16:01, Jacob Carlborg <doob@me.com> a écrit :

> On 12 maj 2013, at 17:53, Michel Fortin <michel.fortin@michelf.ca> wrote:
> 
>> I note that your file has L_OBJC_METH_VAR_NAME_0, L_OBJC_METH_VAR_NAME_2, L_OBJC_METH_VAR_NAME_4 (incrementing by two each time) while my old alpha had L_OBJC_METH_VAR_NAME_0, L_OBJC_METH_VAR_NAME_1, L_OBJC_METH_VAR_NAME_2, incrementing by one... I don't think this is the problem though.
> 
> I'm pretty sure it's the opposite way. Example, on this line you're incrementing "classnamecount":
> 
> https://github.com/michelf/dmd/blob/d-objc/src/objc.c#L378
> 
> Then again on line 381.

Hum, you're right. Anyway that's surely not the culprit.


>> Which D file are you using to make this object file?
> 
> This one:
> 
> https://github.com/jacob-carlborg/dmd/blob/objc_merge/test_objc/runnable/objc_call.d

You should also check what you're linking with. If you're linking against the custom druntime with Objective-C support (as it happens normally with this test), the culprit may well be in one of those druntime objc support functions too. In this case _dobjc_throwAs_d is referenced (which will convert Objective-C exceptions to D exceptions).

There are other tests in this folder. If you try the objc_selector.d test, it should give you some insight whether the problem has to do with the selector literals. It'll probably fail too, but in this case if you comment out the function calls made through the selector variables (so it won't reference anything special in druntime for exceptions) and you'll have a much more isolated test.

-- 
Michel Fortin
michel.fortin@michelf.ca
http://michelf.ca/

_______________________________________________
dmd-internals mailing list
dmd-internals@puremagic.com
http://lists.puremagic.com/mailman/listinfo/dmd-internals

On May 12, 2013, at 10:53 PM, Michel Fortin <michel.fortin@michelf.ca> wrote:

> You should also check what you're linking with. If you're linking against the custom druntime with Objective-C support (as it happens normally with this test), the culprit may well be in one of those druntime objc support functions too. In this case _dobjc_throwAs_d is referenced (which will convert Objective-C exceptions to D exceptions).
>
> There are other tests in this folder. If you try the objc_selector.d test, it should give you some insight whether the problem has to do with the selector literals. It'll probably fail too, but in this case if you comment out the function calls made through the selector variables (so it won't reference anything special in druntime for exceptions) and you'll have a much more isolated test.

The reason why I'm suspecting the selectors is, I run an object dumper that I found in the linker sources. It fails on line 402:

http://www.opensource.apple.com/source/ld64/ld64-134.9/ld64-134.9/src/other/ObjectDump.cpp

I printed "leftString" and "rightString", and run the tool on an object file that works, they both contain selector names.

--
/Jacob Carlborg

On May 12, 2013, at 10:53 PM, Michel Fortin <michel.fortin@michelf.ca> wrote:

> You should also check what you're linking with. If you're linking against the custom druntime with Objective-C support (as it happens normally with this test), the culprit may well be in one of those druntime objc support functions too. In this case _dobjc_throwAs_d is referenced (which will convert Objective-C exceptions to D exceptions).
>
> There are other tests in this folder. If you try the objc_selector.d test, it should give you some insight whether the problem has to do with the selector literals. It'll probably fail too, but in this case if you comment out the function calls made through the selector variables (so it won't reference anything special in druntime for exceptions) and you'll have a much more isolated test.

I tried compiling the code from the objc_selector.d test. Unmodified I get the linker assertion. If I remove all the calls to the selectors the assertion goes away. I then tried linking with a standard druntime and stubbed out _dobjc_throwAs_d, then I don't get the assertion even when the selectors are called. You might be right that the issue is in fact some code from druntime. I also noted that there is some code that doesn't work, either doesn't compile or asserts in the compiler. I guess I should try and address those first.

--
/Jacob Carlborg