On 05.03.2013 15:50, Walter Bright wrote:
>
> On 3/1/2013 9:38 AM, Rainer Schuetze wrote:
>> 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.
>>
>>
>> - 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.

I don't think it's a good idea to cripple the language for a nuisance by an underpowered linking mechanism. E.g. not being able to use the same static initializers as when linking statically would be annoying. To avoid that in C/C++ runtime initializer functions are created (they do anything else than the proposed patching).

How do you want to deal with references to data objects from code? Annotate everything with "export" (which is an "import" depending on whether an initializer follows or not)? That will break the use of the same code for static libraries as the "_imp_" symbols will be missing.

The only option I see is to use indirections for all data accesses, with the data pointer being in the import table or elsewhere. That might be causing linker problems, but at least that seems feasible at the cost of some runtime performance loss.

_______________________________________________
D-runtime mailing list
D-runtime@puremagic.com
http://lists.puremagic.com/mailman/listinfo/d-runtime

On 3/5/2013 12:01 PM, Rainer Schuetze wrote:
> On 05.03.2013 15:50, Walter Bright wrote:
>>
>> On 3/1/2013 9:38 AM, Rainer Schuetze wrote:
>>> 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.
>>>
>>>
>>> - 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.
>
> I don't think it's a good idea to cripple the language for a nuisance by an underpowered linking mechanism. E.g. not being able to use the same static initializers as when linking statically would be annoying. To avoid that in C/C++ runtime initializer functions are created (they do anything else than the proposed patching).
>
> How do you want to deal with references to data objects from code? Annotate everything with "export" (which is an "import" depending on whether an initializer follows or not)? That will break the use of the same code for static libraries as the "_imp_" symbols will be missing.

That's what the "export" protection level was designed for. (It'll serve both purposes, no need for import as well.)

>
> The only option I see is to use indirections for all data accesses, with the data pointer being in the import table or elsewhere. That might be causing linker problems, but at least that seems feasible at the cost of some runtime performance loss.

I think on Windows that people are used to having a different interface when crossing DLL boundaries. Me, I think it's a terrible user code design to pass global data that way.
_______________________________________________
D-runtime mailing list
D-runtime@puremagic.com
http://lists.puremagic.com/mailman/listinfo/d-runtime

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.

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.
_______________________________________________
D-runtime mailing list
D-runtime@puremagic.com
http://lists.puremagic.com/mailman/listinfo/d-runtime

On 05.03.2013 22:58, Walter Bright wrote:
>
> On 3/5/2013 12:01 PM, Rainer Schuetze wrote:
>> On 05.03.2013 15:50, Walter Bright wrote:
>>>
>>> On 3/1/2013 9:38 AM, Rainer Schuetze wrote:
>>>> 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.
>>>>
>>>>
>>>> - 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.
>>
>> I don't think it's a good idea to cripple the language for a nuisance
>> by an underpowered linking mechanism. E.g. not being able to use the
>> same static initializers as when linking statically would be annoying.
>> To avoid that in C/C++ runtime initializer functions are created (they
>> do anything else than the proposed patching).
>>
>> How do you want to deal with references to data objects from code?
>> Annotate everything with "export" (which is an "import" depending on
>> whether an initializer follows or not)? That will break the use of the
>> same code for static libraries as the "_imp_" symbols will be missing.
>
> That's what the "export" protection level was designed for. (It'll serve
> both purposes, no need for import as well.)
>

That will make the source unusable as a static library, which is a horrible idea. You will also need two versions of the files, one with initalizer/function implementation, and one without. di-file generation might help but comes with its own set of problems.


>>
>> The only option I see is to use indirections for all data accesses,
>> with the data pointer being in the import table or elsewhere. That
>> might be causing linker problems, but at least that seems feasible at
>> the cost of some runtime performance loss.
>
> I think on Windows that people are used to having a different interface
> when crossing DLL boundaries. Me, I think it's a terrible user code
> design to pass global data that way.

I think it is inevitable in D, e.g. with runtime reflection and module dependencies.

_______________________________________________
D-runtime mailing list
D-runtime@puremagic.com
http://lists.puremagic.com/mailman/listinfo/d-runtime

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) ;-)


_______________________________________________
D-runtime mailing list
D-runtime@puremagic.com
http://lists.puremagic.com/mailman/listinfo/d-runtime