D on Windows Phone

[bitwise via Digitalmars-d]

On Wed, 01 Jul 2015 15:04:16 -0400, Jacob Carlborg <doob at me.com> wrote:
> Could you try using C? I know Clang/GCC has a lot of attributes,  
> something like __attribute__((section ("<section name<"))) or similar.

I was thinking about this, but it won't work because we have no control  
over what linker will be used to link the object files produced by dmd.  
One idea is to embed the sections-init function as a string in dmd and  
just compile it with gcc. dmd already uses gcc to do linking on OSX. I  
don't think it's reasonable though to expect people to know they should  
compile the extra "entry.o" they find in their object directory when  
building dylibs.

Another idea is to require a D entry point for D DLLs. So when dmd found a  
module in which an entry point was defined, it could dump the  
sections-init function there, the same way that dmd already does for  
application-main. The user would surely expect to have to link the object  
file containing the entry point. The problem with this approach, is that  
again, we have no control over the linker that will be used. This means  
that there is no way to enforce that an entry point be present in D DLLs.  
For C/C++, a main entry point is required, and linking an application  
without it will cause a linker error. I'm not sure if this is built into  
C/C++ linkers in a standard way, or whether the C runtime library has a  
reference to the main() symbol, but without fail, a linker error will  
occur when linking an application without main(). Now, adding a D  
application main function to a module causes dmd to dump a C application  
main into the same output file for that module, thus satisfying the  
requirement for a main entry point. But, the C/C++ runtime/linker does not  
require any kind of entry point for DLLs on OSX. So there would be no way  
to enforce that D DLLs have an entry point(that I can think of), and  
trying to use a dylib which has not had their runtime/sections initialized  
would result in very strange and unpredictable crashes. I really doubt  
most coders would be able to figure out that it was because their D DLL  
main function was missing.

Finally, Martin's solution is to just put the sections-init function in  
_every_ object file, but as COMDAT. This means that the function  
definitions will be treated like template definitions, and the linker will  
just pick the first one it finds at link-time if there are multiple  
definitions. In order to do this, Martin has basically added code to dmd's  
backend for linux/freebsd which manually outputs this stuff to every  
object file.

So the question is, from the point specified above, how do we get the C  
code in there? One way would be have dmd compile the function and spit out  
an object file. But then, dmd would have to be able to read that object  
file, extract it's contents, and reinject it into the D object files. I'm  
not sure this would be any easier than just outputting the function  
manually.

I've been thinking about making the function in D and just parsing it like  
this:
https://github.com/D-Programming-Language/dmd/blob/master/src/mars.c#L233

Once I had the above AST, I could hack it a bit to make it private/local  
COMDAT, then output it to all the object files. At this point though, I'm  
not sure the OSX backend for dmd even knows how to put out private/local  
symbols.

I'm going to revisit this once I've finished familiarizing myself with  
Mach-O format, but if you have any ideas..... :)

   Bit