On 23 Feb 2013 22:00, "Ben Davis" <ent...@cantab.net> wrote: > > On 23/02/2013 18:38, Iain Buclaw wrote: >> >> >> On Feb 23, 2013 6:20 PM, "Ben Davis" <ent...@cantab.net >> <mailto:ent...@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';
