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