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?
