Build on mingw-w64

[ghost]

No description provided.

[kinke]

Thanks - how are the tests looking?

[ghost]

Druntime is working pretty well but phobos is crashing for some reason.
So now i will try to fix phobos, you can check progress here https://github.com/wirx6/phobos/commits/mingw-fix

[ghost]

There probably is another problem with initialization/gc
Working:

int main(){
	FILE* s = fopen("test.txt", "rw");
	fprintf(s,"test");
	fclose(s);
	return 0;
}

Segfault:

void main(){
	FILE* s = fopen("test.txt", "rw");
	fprintf(s,"test");
	fclose(s);
}

EXCEPTION_DEBUG_INFO:
           dwFirstChance: 1
           ExceptionCode: C0000005 (EXCEPTION_ACCESS_VIOLATION)
          ExceptionFlags: 00000000
        ExceptionAddress: 000000000046A4E0 app.000000000046A4E0
        NumberParameters: 2
ExceptionInformation[00]: 0000000000000000 Read
ExceptionInformation[01]: 000000000D5E6340 Inaccessible Address
First chance exception on 000000000046A4E0 (C0000005, EXCEPTION_ACCESS_VIOLATION)!

[JohanEngelen]

was dropping the first extern intended?

[kinke]

Oh, good catch! That's definitely wrong, as the symbols are left initialized with nulls, and the GC doesn't have a single global as GC root.

[kinke]

More context: these symbols are to be provided by the linker. An extra underscore is prepended by LDC automatically.

[kinke]

See https://github.com/msysgit/msys/blob/master/winsup/cygwin/winsup.h#L262. I think the previous code was correct - taking the address is necessary, and the old names should match as well.

[kinke]

Oh and please don't touch the MSVC part in a functional way, that was working fine when 0.17 was released. ;) [You removed the extern there too - thinking it was just a typo? extern(C) extern would look better.]

[ghost]

Sorry my mistake but for some reason ldc is not adding that underscore.

libdruntime-ldc.a(sections_ldc.obj):(.text[_D2rt12sections_ldc12initSectionsFZv]+0x1ce): undefined reference to `_data_start__'
libdruntime-ldc.a(sections_ldc.obj):(.text[_D2rt12sections_ldc12initSectionsFZv]+0x1d5): undefined reference to `_bss_end__'

Maybe someone more experienced will take care of the sections.

[kinke]

Validating the symbols exist (and checking their mangled names via objdump I guess) should be easy with a C file:

#include <stdio.h>
int global;
extern char _data_start__, _data_end__;
int main() {
  printf("%p, %p, %p\n", &global, &_data_start__, &_data_end__);
  return 0;
}

[ghost]

$ clang -c -o test.o test.c && nm test.o && clang -o test.exe test.o
0000000000000000 b .bss
0000000000000000 d .data
0000000000000000 p .pdata
0000000000000000 r .rdata
0000000000000000 t .text
0000000000000000 r .xdata
                 U __main
                 U _data_end__
                 U _data_start__
0000000000000004 C global
0000000000000000 T main
                 U printf
test.o:(.text+0x27): undefined reference to `_data_start__'
test.o:(.text+0x2e): undefined reference to `_data_end__'

[kinke]

Erm you're using clang? Please provide some more details about your environment, starting with Windows version, toolchain(s), used linker etc.

[ghost]

I am using 64 bit mingw-w64 delivered by msys2(http://www.msys2.org/). GCC is producing same symbols as clang.

[kinke]

You answered just one aspect - at least the linker would be good to know as well.

For MSVC, those symbols are derived from the binary's headers at startup: https://github.com/ldc-developers/druntime/blob/ldc-ltsmaster/src/ldc/msvc.c. That file is currently excluded in runtime/CMakeLists.txt for non-MSVC targets (see here). You may want to try adding it (clang may support the MSVC pragmas) and use it in rt.sections* just like MSVC (i.e., not taking their address).

[ghost]

Clang on mingw is not supporting MSVC's pragmas and also has different preprocessor defines.
This code may work because mingw is using MS crt at all but need to be redesigned.

[JohanEngelen]

@wirx6 Those symbols are magic linker symbols, so the exact symbolnames that you need depend solely on the linker used. Perhaps because you are targeting mingw you have to use Linux-like linker magic symbolnames. These magic linker symbolnames are quite badly documented... so it's a bit of a pain to figure it out. http://www.airs.com/blog/archives/56
I'm not sure whether such magic names exist for the .data section.

I see that in LDC master, we use a different mechanism to find the start and end of the data section.

druntime/src/rt/sections_win64.d

Line 80 in 822017a

void[] dataSection = findImageSection(".data");

Backporting that is an alternative path you can try.

[dnadlinger]

If you have a look at an old commit from before MSVC support was merged, data range registration was definitely working on mingw-w64. I don't quite remember everything that has changed since on Windows, though.

[ghost]

@JohanEngelen I backported it and still getting the same error(I will leave it because it solves undefined symbols problem).
Maybe problem is somewhere else.

[kinke]

I just reluctantly installed MSYS2 and mingw-w64-x86_64-gcc. An additional leading underscore was needed (and not zero-initializing the global), then the symbols are there and seem plausible when linking with ld (v2.29.1) via gcc (v7.2.0).

#include <stdio.h>
int global = 123;
extern char __data_start__, __data_end__;
int main() {
  printf("%p, %p, %p\n", &global, &__data_start__, &__data_end__);
  return 0;
}

nm data.exe
00000000004030b0 D __data_end__
0000000000403000 D __data_start__

On Win64, LDC doesn't prepend the C underscore for C symbols (Win32 only), so you'll need to declare it with 2 leading underscores in druntime.

[ghost]

Thats what I got when added -d-debug=PRINTF to D_Flags

initSections called
_d_newclass(ci = 00000000004C1F20, core.thread.Thread)
 p = 0000000002720000
p = 0000000002720000
ci = 00000000004C1F20, ci.init.ptr = 00000000005043C0, len = 304
vptr = 00000000005044F0
vtbl[0] = 00000000004C1F20
vtbl[1] = 00000000004676B0
init[0] = 5044f0
init[1] = 0
init[2] = 0
init[3] = 0
init[4] = 0
initialization done
initTLSRanges called
0000000001101F60.Gcx::addRange(000000000049E000, 000000000051EA20)
Found RtlCaptureStackBackTrace
DbgHelp Version 4.0.5

So segfault happens somewhere there

druntime/src/core/sys/windows/stacktrace.d

Lines 398 to 409 in 9ec9ff4

	printf("DbgHelp Version %d.%d.%d\n", dbghelpVersion.MajorVersion, dbghelpVersion.MinorVersion, dbghelpVersion.Revision);
	}
	HANDLE hProcess = GetCurrentProcess();
	DWORD symOptions = dbghelp.SymGetOptions();
	symOptions |= SYMOPT_LOAD_LINES;
	symOptions |= SYMOPT_FAIL_CRITICAL_ERRORS;
	symOptions |= SYMOPT_DEFERRED_LOAD;
	symOptions = dbghelp.SymSetOptions( symOptions );
	debug(PRINTF) printf("Search paths: %s\n", generateSearchPath().ptr);

[ghost]

Operator ~= is crashing for some reason
Segfault:

auto a = "Hello";
a ~= " world!";

Working:

auto a = "Hello";
a = format("%s world!",a);

Beside of this anything seems to be fine

initSections called
_d_newclass(ci = 00000000004C4050, core.thread.Thread)
 p = 0000000002710000
p = 0000000002710000
ci = 00000000004C4050, ci.init.ptr = 0000000000506850, len = 304
vptr = 0000000000506980
vtbl[0] = 00000000004C4050
vtbl[1] = 000000000046A640
init[0] = 506980
init[1] = 0
init[2] = 0
init[3] = 0
init[4] = 0
initialization done
initTLSRanges called
0000000000F61750.Gcx::addRange(00000000004A0000, 0000000000520A20)
Found RtlCaptureStackBackTrace
DbgHelp Version 4.0.5
Search paths: (null)
Hello world!
processing GC Marks, 0
finiSections called

[kinke]

I pushed a cleanup commit and verified the changes against current MinGW-w64 headers; should be fine except for [most likely irrelevant] stdin/out/err initialization (MinGW seems to use the normal MSVC infrastructure on Win64, but making ltsmaster use that for MinGW would be tedious and seems unnecessary).

[kinke]

@wirx6: Please verify that it's still working like before, my MSYS environment isn't set up for building LDC. Will merge then.

[kinke]

Got my environment to build now; druntime compiles fine.

[ghost]

@kinke I made a PKGBUILD script for testing purposes.
Can be built with command makepkg-mingw -s.
pk.zip
pacman -U *.pkg.tar.xz to install in mingw environment.