On Sat, 06 Jun 2015 16:04:33 -0400, Walter Bright
<[email protected]> wrote:
On 6/6/2015 12:09 PM, bitwise wrote:
On Sat, 06 Jun 2015 14:52:11 -0400, bitwise <[email protected]>
wrote:
Any ideas on this would be much appreciated.
Thanks,
Bit
One thought that just occurred to me would be to require that D dynamic
libraries contain a main entry point, like DllMain on Windows. This
seems like
the only real/reliable option.
The coder would have to explicitly give dmd a module in which to place
the
constructor/destructor code for images, the same way that dmd adds a
C-main in
the file where D-main is found. Enforcing this in the future would be a
breaking
change, but not a dangerous one. It would be a simple link-time error
which was
easy to fix.
Also, requiring all D binaries to have some kind of entry point would
alleviate
the need to ever call Runtime.initialize() explicitly.
Bit
Martin Nowak is the author of most of the OSX DLL support, but he seems
to not be around lately.
I'd rather have a dynamic library entry point than put a
constructor/destructor call into every object file.
Right. I was wondering what he was doing there...Just learned what COMDAT
is ;)
It's starting to look like reworking druntime was the easy part. I've got
druntime built as a shared library now, and my main project, which thus
far is an app/graphics/game engine, is working nicely. Of course, all this
goes out the window with a C-Host app... unless people knew to link the
shared druntime with their C host app, which doesn't sound intuitive.
I like the idea of a dll entry point though.
I suppose it could look something like this:
enum Reason {
processAttach,
processDetach,
threadAttach,
threadDetatch
}
bool main(void *handle, Reason reason) {
return true;
}
For windows, we could simply hijack DllMain().
As for the OSX, we could use an entry point stub like this, with the rest
of the code in druntime:
// dladdr(&symbol) gets us the mach_image*
void _osx_image_init(void *symbol);
void _osx_image_term(void *symbol);
__attribute__((visibility("hidden"), constructor))
static void _image_init() {
_osx_image_init((void*)&_image_init);
}
__attribute__((visibility("hidden"), destructor))
static void _image_term(){
_osx_image_term((void*)&_image_term);
}
I would like to do the above stub in D, but I haven't found a way to
specify visibility or section of the function yet.
I would rather not do what Martin has done, outputting the entire thing in
asm, as that would take me a very long time to get right.
Anyways, onward!
Thanks
Bit
