[D-runtime] druntime should be a shared library/DLL

[Rainer Schuetze]

On 15.02.2013 23:34, Rainer Schuetze wrote:
> On 08.02.2013 14:00, Andrei Alexandrescu wrote:
>> On 2/8/13 2:18 AM, Rainer Schuetze wrote:
>>> On 06.02.2013 23:15, Walter Bright wrote:> This would go a long ways
>>> towards solving the dll issue, as then the gc
>>>  > and thread instances will automatically be shared.
>>>
>>> Time to dig up http://d.puremagic.com/issues/show_bug.cgi?id=4071 again.
>>> I had implemented a working shared phobos.dll at that time. I can try to
>>> bring it up to date if the approach seems appropriate.
>>
>> Yes please, that would be awesome.
>>
>> Andrei
>
> I've spent some time on it and have created a Win32 druntime DLL. Stay
> tuned for some pull requests to come after a few cleanups...

Sorry for the delay, I couldn't work on it for a couple of days and 
faced an unexpected problem with relocation to data:

IMO using the import functionality of "export" to support data imports 
through the import table is not an option as it pollutes the code (you 
might even need two different sources when building against a shared or 
static library) and introduces restrictions (like not being able to use 
the address of an imported symbol in static data initializers). That's 
why I am following the idea to patch code to refer to data in the shared 
library.

- The old patch in bugzilla walked the relocation information in the 
executable and analyzed the data: if it refers to some entry in the 
import table it gets patched with the actual address in the shared library.

- Unfortunately this does not work when there is an offset applied to 
the relocation, because you can no longer identify the entry in the 
import table. I implemented another indirection through some extra data 
to detect offsets within the referred data, but that's both ugly and 
unsafe in case the optimizer generates code with offsets outside the 
original data range.

- Instead, I patched dmd to emit extra relocation information to be 
collected in some data segment. This works for references from data, but 
as functions are generated into comdats the only sensible way to add 
this data is to use comdats aswell. Unfortunately again, comdats cannot 
be assigned to a separate segment according to the OMF spec, so they are 
merged with other data and you cannot identify the relocation 
information in the image anymore.

- For COFF, there is the concept of "associated" segments (also used by 
".pdata" sections), that are added to the binary if the other segment is 
linked in. Implementing this for Win64 revealed another problem: code is 
generated with PC-relative data accesses, so patching the code to refer 
to a DLL far away in the 64-bit address space does not work.

So I ended up with only Win32-COFF working with this concept so far...

Questions:
- Is there a way to have something similar as "associated" segments with 
the OMF object format?

- Is it possible to force generation of absolute accesses to external 
data in Win64?

- What is happening on linux? I guess there is no import table there so 
relocations are pointing directly into the shared library, but what 
about PC relative adressing?

- Is there something wrong with the whole concept?