On 06.09.2011 22:51, Rainer Schuetze wrote:
> On 06.09.2011 22:45, Walter Bright wrote:
>>
>>
>> On 9/6/2011 12:13 PM, Rainer Schuetze wrote:
>>>
>>> I can reproduce the issue on Win7 64, but not on XP. I have debugged it a little until I noticed that the generated code for TLS access seems broken:
>>>
>>> dmd 2.054 generated this code for the append operation
>>>
>>>  push        1
>>> 1000207D  mov         ecx,dword ptr [__tls_index (1006BF98h)]
>>> 10002083  mov         edx,dword ptr fs:[2Ch]
>>> 1000208A  mov         ebx,dword ptr [edx+ecx*4]
>>> 1000208D  lea         esi,[ebx+4]
>>> 10002093  push        esi
>>> 10002094  mov         eax,offset TypeInfo_Ai at __init (1005E9A0h)
>>> 10002099  push        eax
>>> 1000209A  call        __d_arrayappendcT (10004D68h)
>>>
>>> while the beta generates
>>>
>>> push        1
>>> 10002076  mov         ecx,dword ptr fs:[2Ch]
>>> 1000207D  mov         edx,dword ptr [ecx]
>>> 1000207F  lea         ebx,[edx+4]
>>> 10002085  push        ebx
>>> 10002086  mov         esi,offset TypeInfo_Ai at __init (10067A90h)
>>> 1000208B  push        esi
>>> 1000208C  call        __d_arrayappendcT (10004F9Ch)
>>>
>>> so it completely ignores the tls_index. I guess it works on XP because there are less DLLs that use TLS, so the DLLs index ends up as 0.
>>>
>>
>> Very interesting. Can you provide the source code for that?
>>
>>
>> _______________________________________________
>> dmd-beta mailing list
>> dmd-beta at puremagic.com
>> http://lists.puremagic.com/mailman/listinfo/dmd-beta
> it seems to happen with any code:
>
> int x;
>
> int main()
> {
>         return x;
> }
>
> generates
>
> __Dmain comdat
>         assume  CS:__Dmain
>                 mov     EAX,FS:__tls_array
>                 mov     ECX,[EAX]
>                 mov     EAX,_D1m1xi[ECX]
>                 ret
> __Dmain ends
>

Sorry, this is wrong. This is the usual exe-only optimization that assumes tls_index==0. It seems the command line options do not suggest that a DLL is generated. I'll try to reduce it...


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puremagic.com/pipermail/dmd-beta/attachments/20110906/e07afe2a/attachment.html>

On 06.09.2011 23:05, Rainer Schuetze wrote:
> On 06.09.2011 22:51, Rainer Schuetze wrote:
>> On 06.09.2011 22:45, Walter Bright wrote:
>>>
>>>
>>> On 9/6/2011 12:13 PM, Rainer Schuetze wrote:
>>>>
>>>> I can reproduce the issue on Win7 64, but not on XP. I have debugged it a little until I noticed that the generated code for TLS access seems broken:
>>>>
>>>> dmd 2.054 generated this code for the append operation
>>>>
>>>>  push        1
>>>> 1000207D  mov         ecx,dword ptr [__tls_index (1006BF98h)]
>>>> 10002083  mov         edx,dword ptr fs:[2Ch]
>>>> 1000208A  mov         ebx,dword ptr [edx+ecx*4]
>>>> 1000208D  lea         esi,[ebx+4]
>>>> 10002093  push        esi
>>>> 10002094  mov         eax,offset TypeInfo_Ai at __init (1005E9A0h)
>>>> 10002099  push        eax
>>>> 1000209A  call        __d_arrayappendcT (10004D68h)
>>>>
>>>> while the beta generates
>>>>
>>>> push        1
>>>> 10002076  mov         ecx,dword ptr fs:[2Ch]
>>>> 1000207D  mov         edx,dword ptr [ecx]
>>>> 1000207F  lea         ebx,[edx+4]
>>>> 10002085  push        ebx
>>>> 10002086  mov         esi,offset TypeInfo_Ai at __init (10067A90h)
>>>> 1000208B  push        esi
>>>> 1000208C  call        __d_arrayappendcT (10004F9Ch)
>>>>
>>>> so it completely ignores the tls_index. I guess it works on XP because there are less DLLs that use TLS, so the DLLs index ends up as 0.
>>>>
>>>
>>> Very interesting. Can you provide the source code for that?
>>>
>>>
>>> _______________________________________________
>>> dmd-beta mailing list
>>> dmd-beta at puremagic.com
>>> http://lists.puremagic.com/mailman/listinfo/dmd-beta
>> it seems to happen with any code:
>>
>> int x;
>>
>> int main()
>> {
>>         return x;
>> }
>>
>> generates
>>
>> __Dmain comdat
>>         assume  CS:__Dmain
>>                 mov     EAX,FS:__tls_array
>>                 mov     ECX,[EAX]
>>                 mov     EAX,_D1m1xi[ECX]
>>                 ret
>> __Dmain ends
>>
>
> Sorry, this is wrong. This is the usual exe-only optimization that assumes tls_index==0. It seems the command line options do not suggest that a DLL is generated. I'll try to reduce it...
>

A simple example is this:

module dllmain;
import std.c.windows.windows;

int test;

extern (Windows)
BOOL DllMain(HINSTANCE hInstance, ULONG ulReason, LPVOID pvReserved)
{
     test = 1;
     return true;
}

to be compiled with
dmd -g -v -oftest.dll dll.def -L/SUBSYSTEM:WINDOWS dllmain.d


The problem is, that backend_init() is called before the files on the command line are processed. So, global.params.deffile is always 0 when config.wflags is set in out_config_init(), and the code generation thinks it is generating an executable.

Though unused by dmd, the deffile looks like this for completeness:
LIBRARY "test.dll"
  EXETYPE NT
  SUBSYSTEM WINDOWS
  CODE SHARED EXECUTE
  DATA WRITE
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puremagic.com/pipermail/dmd-beta/attachments/20110906/b45fa747/attachment.html>

On Tue, 6 Sep 2011, Rainer Schuetze wrote:

> On 06.09.2011 23:05, Rainer Schuetze wrote:
> A simple example is this:
> 
> module dllmain;
> import std.c.windows.windows;
> 
> int test;
> 
> extern (Windows)
> BOOL DllMain(HINSTANCE hInstance, ULONG ulReason, LPVOID pvReserved)
> {
>     test = 1;
>     return true;
> }
> 
> to be compiled with
> dmd -g -v -oftest.dll dll.def -L/SUBSYSTEM:WINDOWS dllmain.d
> 
> 
> The problem is, that backend_init() is called before the files on the command line are processed. So, global.params.deffile is always 0 when config.wflags is set in out_config_init(), and the code generation thinks it is generating an executable.
> 
> Though unused by dmd, the deffile looks like this for completeness:
> LIBRARY "test.dll"
>  EXETYPE NT
>  SUBSYSTEM WINDOWS
>  CODE SHARED EXECUTE
>  DATA WRITE
> 

Damn.. that one would be my changes then.  If the choice is to revert then the fix to iasm.d that depends on the changes to backend_init will also need to be reverted (also re-opening the closed bug associated with it).

I'm not in a good position to spend much time digging into this right now, but on quick inspection of the code, in mars.c, try moving the call of backend_init to after the module creation loop, before the try.

-------------- next part --------------
_______________________________________________
dmd-beta mailing list
dmd-beta at puremagic.com
http://lists.puremagic.com/mailman/listinfo/dmd-beta

On 9/6/2011 3:07 PM, Brad Roberts wrote:
>
> Damn.. that one would be my changes then.  If the choice is to revert then the fix to iasm.d that depends on the changes to backend_init will also need to be reverted (also re-opening the closed bug associated with it).
>
> I'm not in a good position to spend much time digging into this right now, but on quick inspection of the code, in mars.c, try moving the call of backend_init to after the module creation loop, before the try.

I've checked in a patch for that. Rainer, want to give it a try?

https://github.com/D-Programming-Language/dmd/commit/b60b44fda4be65df75149d4c772a84698a69a544

BTW, thanks S?nke, Rainer and Brad for your quick action in finding the cause of this problem.

On 07.09.2011 02:21, Walter Bright wrote:
>
>
> On 9/6/2011 3:07 PM, Brad Roberts wrote:
>>
>> Damn.. that one would be my changes then.  If the choice is to revert
>> then
>> the fix to iasm.d that depends on the changes to backend_init will also
>> need to be reverted (also re-opening the closed bug associated with it).
>>
>> I'm not in a good position to spend much time digging into this right
>> now,
>> but on quick inspection of the code, in mars.c, try moving the call of
>> backend_init to after the module creation loop, before the try.
>
> I've checked in a patch for that. Rainer, want to give it a try?
>
> https://github.com/D-Programming-Language/dmd/commit/b60b44fda4be65df75149d4c772a84698a69a544
>
> _______________________________________________

Sorry, I could not answer while I was asleep. The new beta works fine.

I'm not sure about Brads concerns, but the new position of the call to backend_init() is between parsing+importing+expanding version/debug conditionals and semantic analysis. This seems fine, but maybe there is something depending on backend initialization? backend_init could also move before the parsing...

On Tuesday, September 06, 2011 11:35:00 PM, Rainer Schuetze wrote:
> On 07.09.2011 02:21, Walter Bright wrote:
>>
>>
>> On 9/6/2011 3:07 PM, Brad Roberts wrote:
>>>
>>> Damn.. that one would be my changes then.  If the choice is to revert then the fix to iasm.d that depends on the changes to backend_init will also need to be reverted (also re-opening the closed bug associated with it).
>>>
>>> I'm not in a good position to spend much time digging into this right now, but on quick inspection of the code, in mars.c, try moving the call of backend_init to after the module creation loop, before the try.
>>
>> I've checked in a patch for that. Rainer, want to give it a try?
>>
>> https://github.com/D-Programming-Language/dmd/commit/b60b44fda4be65df75149d4c772a84698a69a544 _______________________________________________
> 
> Sorry, I could not answer while I was asleep. The new beta works fine.
> 
> I'm not sure about Brads concerns, but the new position of the c
all to backend_init() is between
> parsing+importing+expanding version/debug conditionals and semantic analysis. This seems fine, but maybe there is something depending on backend initialization? backend_init could also move before the parsing...

It's ok where it is I'm pretty sure.  The iasm dependency doesn't kick in until semantic analysis.  If there's anything in lexing and parsing that interfaces with the backend, I'd love to know about it.