<p><br>
On 23 Feb 2013 22:00, "Ben Davis" <<a href="mailto:entheh@cantab.net">entheh@cantab.net</a>> wrote:<br>
><br>
> On 23/02/2013 18:38, Iain Buclaw wrote:<br>
>><br>
>><br>
>> On Feb 23, 2013 6:20 PM, "Ben Davis" <<a href="mailto:entheh@cantab.net">entheh@cantab.net</a><br>
>> <mailto:<a href="mailto:entheh@cantab.net">entheh@cantab.net</a>>> wrote:<br>
>>  ><br>
>>  > Hi,<br>
>>  ><br>
>>  > Has anyone had any success using GDC to make DLLs to be called from<br>
>> C/C++?<br>
>>  ><br>
>>  > The reason I ask is, for me, the following snippet inside dll.d /<br>
>> dll_fixTLS() seems to have compiled to a call to abort():<br>
>>  ><br>
>>  >         void** peb;<br>
>>  >         asm<br>
>>  >         {<br>
>>  >             mov EAX,FS:[0x30];<br>
>>  >             mov peb, EAX;<br>
>>  >         }<br>
>>  ><br>
>>  > and thus dll_process_attach() crashes the process.<br>
>>  ><br>
>>  > It seems like a bug that would affect more people than just me, yet I<br>
>> couldn't find any evidence of other people hitting it. Have I got it<br>
>> right what's happening, or is something else at work?<br>
>>  ><br>
>>  > If I'm right, then I'm just wondering if anyone has any ideas on<br>
>> whether it could be fixed, and how?<br>
>>  ><br>
>>  > Also, I found some discussion about D-style inline asm being<br>
>> problematic and worthy of removal, but didn't find any explanation as to<br>
>> what those problems were. I'm curious :)<br>
>>  ><br>
>><br>
>> Only because shared libraries requires PIC, and quite a few of the IASM<br>
>> routines clobber the pic register.<br>
><br>
><br>
> I see. :)<br>
><br>
> 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:<br>
><br>
>     static bool tlsCtorRun;<br>
>     static this() { tlsCtorRun = true; }<br>
> 64841F0F 8B 15 D4 E2 95 64    mov         edx,dword ptr ds:[6495E2D4h]<br>
> 64841F15 64 A1 2C 00 00 00    mov         eax,dword ptr fs:[0000002Ch]<br>
> 64841F1B 8B 04 90             mov         eax,dword ptr [eax+edx*4]<br>
> 64841F1E C6 80 1C 50 96 64 01 mov         byte ptr _tls_start+4 (6496501Ch)[eax],1     <-- this line crashes<br>
> 64841F25 5D                   pop         ebp<br>
> 64841F26 C3                   ret<br>
><br>
> 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.<br>

><br>
> 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.<br>

><br>
> Is this a compiler TLS codegen bug?</p>
<p>GDC TLS is differrent to whatever DMD uses, so assembly code that works for DMD may not necessarily be correct for GDC.</p>
<p>Regards<br>
----<br>
Iain Buclaw</p>
<p>*(p < e ? p++ : p) = (c & 0x0f) + '0';</p>