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

[Rainer Schuetze]

On 05.03.2013 23:01, Walter Bright wrote:
>
> On 3/5/2013 11:45 AM, Rainer Schuetze wrote:
>> On 05.03.2013 16:35, Artur Skawina wrote:
>>> On 03/01/13 18:38, Rainer Schuetze wrote:
>>>> - 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?
>>>
>>> http://www.iecc.com/linker/linker10.html
>>>
>>> artur
>>>
>>
>> Thanks for the link. The article seems to be a bit old, though (1999,
>> no 64-bit, seems to compare to XP). Not sure how much has changed since.
>>
>> It isn't clear from the initial description, but the comparison at the
>> end gives me the impression that ELF allows direct data relocations
>> into another shared library very much like what I've tried to
>> implement for Windows.
>>
>> I've tried generating some ELF object files (under windows by
>> compiling for TARGET_LINUX), but I don't see any code generated to
>> support 64-bit data addresses. How is this going to work?
>
> My understanding is the ELF 64 bit ABI does not allow more than 32 bits
> worth of code in an app, i.e. all the code (including shared libraries)
> will be within a 32 bit offset of each other.

According to this document 
http://refspecs.linuxbase.org/elf/x86_64-abi-0.95.pdf 64-bit images and 
relocations are possible (see pages 42ff,66ff). For PIC those accesses 
have to go through the GOT, though.

>
> Also, I tend to answer similar questions by writing a bit of C code
> illustrating the issue, compiling it, and dumping the result. dumpobj
> and obj2asm were crafted for that purpose. It usually answers the
> question - I find the documentation contains too many errors,
> assumptions, and omissions to be reliable.

That's what I did (on windows), but it didn't show anything but the mess 
that it has always been for DLLs (intializer functions, additional 
indirections, etc).

I guess you are used too much to the way C/C++ does it, and want to let 
everybody else suffer too by also not letting #defining away the 
__declspec(dllimport) ;-)