On Tuesday, 10 January 2012 at 01:52:57 UTC, Andrej Mitrovic wrote:
>> Turns out i was right to be worried about ebp - see the vtst()
>> function below...
>
> On DMD head I get an ICE, yay!
> Internal error: backend/cod3.c 446

Like this?:
http://d.puremagic.com/issues/show_bug.cgi?id=7254

Am 10.01.2012 06:02, schrieb Daniel Green:
> 64-bit is ready.
> 
> 64-Bit Binary
> 
> https://bitbucket.org/goshawk/gdc/downloads/gcc-4.6.1-tdm64-1-gdc-9841510e8ba6-20120109.7z

Since some time I try to somehow get a working 64-bit DLL compiled. With gdc this works now apart from crashing in the TLS setup code, as soon as the runtime is initialized (no TLS variables are used in the code).

Is TLS support and/or a workaround for those crashes something that's on the radar?

Regards,
Sönke

> Is TLS support and/or a workaround for those crashes something that's on the radar?

It's a known issue and being worked on I think.

On 1/26/2012 11:01 AM, Sönke Ludwig wrote:
> Is TLS support and/or a workaround for those crashes something that's on
> the radar?
That release had a few issues with generating 64-bit TLS code.  Those issues have been fixed but I haven't uploaded a new binary.  The new compiler can pass most of the testsuite.  The current failures are not TLS related.

Since you're working with Dll's if you post a test case, I would be happy to test the compiler on it before uploading a new release.

TLS is a high priority for MinGW as it is required by D.

Am 27.01.2012 01:32, schrieb Daniel Green:
> On 1/26/2012 11:01 AM, Sönke Ludwig wrote:
>> Is TLS support and/or a workaround for those crashes something that's on the radar?
> That release had a few issues with generating 64-bit TLS code.  Those issues have been fixed but I haven't uploaded a new binary.  The new compiler can pass most of the testsuite.  The current failures are not TLS related.
> 
> Since you're working with Dll's if you post a test case, I would be happy to test the compiler on it before uploading a new release.
> 
> TLS is a high priority for MinGW as it is required by D.
> 

OK that sounds great, thanks for the info. I will prepare a short test case later today.

== Auszug aus Daniel Green (venix1@gmail.com)'s Artikel
> On 1/26/2012 11:01 AM, Sönke Ludwig wrote:
> > Is TLS support and/or a workaround for those crashes something that's on the radar?
> That release had a few issues with generating 64-bit TLS code.  Those
> issues have been fixed but I haven't uploaded a new binary.  The new
> compiler can pass most of the testsuite.  The current failures are not
> TLS related.
> Since you're working with Dll's if you post a test case, I would be
> happy to test the compiler on it before uploading a new release.
> TLS is a high priority for MinGW as it is required by D.

I just realized that the crash happens only when loading the DLL at runtime using LoadLibrary and that it is only partially a 32/64 bit problem (test2c crashes for 64-bit but works for 32-bit).

The attached .zip contains a test script that runs a few different combinations. The statically linked versions generally seem to work.

All tests pass.  However, I see your problem.

In plaindll.d:

version(GNU){ // Workaround for linker error
	void* _tlsstart; // First symbol of the TLS section
	void* _tlsend;
	//int _tls_callbacks_a; // Workaround for GDC/MinGW linker error
}

_tlsstart is the first symbol of the TLS section. _tlsend is the last symbol of the TLS section.  Together they are used by D to identify the TLS memory region for a given thread.  If they do not come from TLS memory then things will not work right.

The MinGW runtime has equivalent symbols __tls_start and __tls_end. This is not something likely to change as it's a Windows convention. The version of MinGW/GDC you have should define _tlsstart and _tlsend symbols automatically if WinMain, DllMain or _Dmain functions exist in the current object file.

As of now MinGW/GDC uses alias __tls_start _tlsstart and alias __tls_end _tlsend to satisfy those requirements where necessary.

It's the same with _tls_callbacks_a.  Windows convention specifies __xl_a.

The currently posted MinGW64 binaries have an alignment issue with TLS memory in 64-bit mode.  It's a segfault that will manifest in the garbage collector.

I'll release updated binaries tonight.