manual memory management

[Rainer Schuetze]

On 09.01.2013 19:57, Benjamin Thaut wrote:
> Am 09.01.2013 16:49, schrieb Andrei Alexandrescu:
>> On 1/9/13 4:25 AM, Benjamin Thaut wrote:
>>> The compiler is not shared-lib ready. At least not on windows. It does
>>> not support exporting data symbols. E.g.
>>>
>>> export uint g_myGlobal;
>>>
>>> This is mostly a problem for "hidden" data symbols, like vtables, module
>>> info objects, type info objects and other stuff D relies on.
>>
>> Are there bugzilla entries for this?
>>
>> Andrei
>
> Yes its pretty old too. If you read through the discussion in the ticket
> and through the code Rainer Schuetze provided you will have a list of
> all the issues that need to be fixed for shared dlls to work:
> http://d.puremagic.com/issues/show_bug.cgi?id=4071

I doubt it is easily mergeable now, but the major points are listed in 
the bug report. Some of the patches are meant as tests whether the 
approach is feasable and should be discussed (like the -exportall switch 
which might be exporting a bit to much, but could not be implemented by 
a def file due to optlink limitations).

>
> In the following patch:
> http://d.puremagic.com/issues/attachment.cgi?id=601&action=edit
> Rainer Schuetze does manual patching for data symbols. But this is
> hardcoded to only work for his phobos shared dll. The function it is
> done in is called dll_patchImportRelocations. If I understand DLLs
> correctly this should usually be done by the import library that is
> created by the compiler for a shared dll. Maybe Rainer can shed some mor
> light on this.

The import library can only help with function calls by providing the 
call target and creating an indirect jump through the import table to 
the actual function in the other DLL.
Data accesses need another indirection through the import table in the 
code if they want to access the actual data in another DLL. This 
indirection is not generated by the compiler. That's why a pass is made 
to patch all relocation into the import table to their respective 
targets (which also eliminates the call indirections). It also has the 
benefit of being able to use the same object files for static or dynamic 
linking.

The hardcoding of the DLL name was meant for testing purposes. What's 
needed is a method to figure out whether the target DLL is written in D 
and that data relocations are actually wrong. That would support sharing 
data between multiple DLLs aswell (It currently only allows sharing 
objects created in the D runtime).


Just to make it clear: I distinguish 2 kinds of DLLs written in D:

1. A DLL that contains the statically linked D runtime and interfaces to 
other DLLs and the application without sharing ownership (as if all 
other DLLs are written in C). This works pretty well on Windows (Visual 
D is such a DLL).

2. A DLL that shares ownership of memory, objects, threads, etc with the 
executable and other DLLs if they are also written in D. This is 
realized by placing the D runtime into its own DLL that is implicitely 
loaded with the other binary. (In contrast to some rumors that I 
remember that on posix systems the runtime would be linked into the 
application image.) This is what the patches in the bugzilla entry 
implement.