Can GDC make DLLs?

[Iain Buclaw]

On 23 Feb 2013 22:00, "Ben Davis" <entheh at cantab.net> wrote:
>
> On 23/02/2013 18:38, Iain Buclaw wrote:
>>
>>
>> On Feb 23, 2013 6:20 PM, "Ben Davis" <entheh at cantab.net
>> <mailto:entheh at cantab.net>> wrote:
>>  >
>>  > Hi,
>>  >
>>  > Has anyone had any success using GDC to make DLLs to be called from
>> C/C++?
>>  >
>>  > The reason I ask is, for me, the following snippet inside dll.d /
>> dll_fixTLS() seems to have compiled to a call to abort():
>>  >
>>  >         void** peb;
>>  >         asm
>>  >         {
>>  >             mov EAX,FS:[0x30];
>>  >             mov peb, EAX;
>>  >         }
>>  >
>>  > and thus dll_process_attach() crashes the process.
>>  >
>>  > It seems like a bug that would affect more people than just me, yet I
>> couldn't find any evidence of other people hitting it. Have I got it
>> right what's happening, or is something else at work?
>>  >
>>  > If I'm right, then I'm just wondering if anyone has any ideas on
>> whether it could be fixed, and how?
>>  >
>>  > Also, I found some discussion about D-style inline asm being
>> problematic and worthy of removal, but didn't find any explanation as to
>> what those problems were. I'm curious :)
>>  >
>>
>> Only because shared libraries requires PIC, and quite a few of the IASM
>> routines clobber the pic register.
>
>
> I see. :)
>
> I've managed to build my DLL with a replacement for dll.d, using
GCC-style inline asm for the offending block. Now I've run into another
problem. This code crashes:
>
>     static bool tlsCtorRun;
>     static this() { tlsCtorRun = true; }
> 64841F0F 8B 15 D4 E2 95 64    mov         edx,dword ptr ds:[6495E2D4h]
> 64841F15 64 A1 2C 00 00 00    mov         eax,dword ptr fs:[0000002Ch]
> 64841F1B 8B 04 90             mov         eax,dword ptr [eax+edx*4]
> 64841F1E C6 80 1C 50 96 64 01 mov         byte ptr _tls_start+4
(6496501Ch)[eax],1     <-- this line crashes
> 64841F25 5D                   pop         ebp
> 64841F26 C3                   ret
>
> It works when built with DMD. The code is functionally identical, and
gets identical values (give or take some randomless with exact memory
layout), with one exception: the offending line effectively says "byte ptr
[eax+10h]" instead. So the constant displacement in the instruction is 10h
instead of 6496501Ch.
>
> I'm no expert on how DLLs are loaded, but I think I've ruled out any
load-time code offset adjustment - because I found the exact sequence of
code bytes in the DLL file on disk, including that number 6496501Ch and all
the surrounding code mnemonics.
>
> Is this a compiler TLS codegen bug?

GDC TLS is differrent to whatever DMD uses, so assembly code that works for
DMD may not necessarily be correct for GDC.

Regards
----
Iain Buclaw

*(p < e ? p++ : p) = (c & 0x0f) + '0';
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puremagic.com/pipermail/d.gnu/attachments/20130224/cdc50310/attachment.html>