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

[Walter Bright]

On 3/1/2013 9:38 AM, Rainer Schuetze wrote:
> 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?

Yes. I'd just stick with the way DLL imports are designed to work, which is the 
extra level of indirection, and just deal with any restrictions that come out of 
that.