Can GDC make DLLs?

[Ben Davis]

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?