On Wed, 01 Jul 2015 15:04:16 -0400, Jacob Carlborg <[email protected]> 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
