Re: [Mingw-w64-public] Sanitizers and MinGW
Hi, On Thu, 27 Aug 2020, Michael Hartmann wrote: I want to use LLVM (clang, clang++) as compiler on Windows in a MinGW environment together with sanitizers (ASAN and UB). I am using the MinGW distribution provided by winlibs.com which is based on MinGW-w64 7.0.0 - release 3 and comes with LLVM 10. Unfortunately, the runtime libraries necessary for ASAN are missing. For this purpose, I'd recommend my llvm based mingw distribution from https://github.com/mstorsjo/llvm-mingw. (See "Releases" on the right hand side.) However, I ran into the problem that sometimes (not reproducable) lld just hangs indefinitely. There have been issues with lld and winpthreads which caused deadlocks in the past. Yes, there's been a few reports of this. I think some of the reported issues might be fixed in the very latest version of winpthreads in the git versions of mingw-w64 - I don't know for sure if all the fixes are in the mingw-w64 7.0.0 release as you're using or not. My builds of lld are built on top of libc++ instead of libstdc++, and libc++ doesn't use winpthreads for its threading on windows, so this issue should not be present in lld in my distribution at all. Or maybe someone knows how to get sanitizers working using GNU ld. The sanitizers rely on a number of exotic linker features, including some added specifically to lld for supporting the sanitizer user case - and GNU ld doesn't support those features, unfortunately. // Martin ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
[Mingw-w64-public] Sanitizers and MinGW
Dear all, I want to use LLVM (clang, clang++) as compiler on Windows in a MinGW environment together with sanitizers (ASAN and UB). I am using the MinGW distribution provided by winlibs.com which is based on MinGW-w64 7.0.0 - release 3 and comes with LLVM 10. Unfortunately, the runtime libraries necessary for ASAN are missing. I compiled the missing runtime libraries myself from the LLVM repository and copied the libraries into the distribution. I was not able to get ASAN working with the GNU ld linker, so I have replaced ld.exe with lld.exe. The effective linker now is the LLVM lld linker. With these changes I am able to compile programs with and without sanitizers activated. However, I ran into the problem that sometimes (not reproducable) lld just hangs indefinitely. There have been issues with lld and winpthreads which caused deadlocks in the past. Maybe, the problem I am facing is similar. When attaching with lldb to a hanging ld.exe program, I see that the process is stuck inside ntdll.dll (function WinDBG or something similar, I don't exactly recall right now). I tried to compile lld myself but was not successful. Using ld as linker does not work for ASAN. And the proposed solution on this site https://github.com/android/ndk/issues/855 to give the lld linker the flag --no-threads does not work because the flag is not known. This is quite strange as the flag is mentioned in the usage text that is shown when running lld with the --help flag. Once the code is compiled the sanitizers and the generated executables work fine. Manually one can just abort the compilation and re-start it if lld hangs. However, I want to automate the build process in a script and hence the hangs are a show stopper. At this point I woud be very happy for any help. Maybe there is a better way to get support for sanitizers than my approach? Maybe there is a workaround for the lld hangups? Maybe someone has a good idea how I can debug why lld.exe hangs or maybe it's a known issue. Or maybe someone knows how to get sanitizers working using GNU ld. I am grateful for any hints. Thank you so much. --Michael ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] runtime difference between code compiled with VS and gcc
在 2020/8/27 下午1:18, Vincent Torri 写道: >> >> In 'mingw-w64-crt/crt/crtexe.c' , `argv` is initialized by the function >> `__getmainargs()` which is imported from MSVCRT. VC >> uses new versions of runtime libraries so it'd be MSVCR100, MSVCR120, etc. >> There might be some differences in the >> aforementioned function. > > that makes sense. Is it possible to tell gcc to use msvcr*.dll instead > of msvcrt.dll ? > The MSYS2 GCC has a patch [1] for the option `-mcrtdll=`. You may try compiling with `-mcrtdll=msvcr140` for example. You probably have to check which version your MSVC uses first. Note that in principle this patch is incorrect. If you want to link against a different CRT DLL then everything - including all indeterminate DLLs - has to be re-compiled. It is not safe to link one DLL against MSVCRT and another one against MSVCR120 and load them in the same process. [1] https://github.com/msys2/MINGW-packages/blob/master/mingw-w64-gcc/0006-Windows-New-feature-to-allow-overriding.patch -- Best regards, LH_Mouse signature.asc Description: OpenPGP digital signature ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] runtime difference between code compiled with VS and gcc
On Thu, Aug 27, 2020 at 8:51 AM Vincent Torri wrote:
>
> On Thu, Aug 27, 2020 at 8:45 AM Ruben Van Boxem
> wrote:
> >
> > Op do 27 aug. 2020 om 07:18 schreef Vincent Torri :
> >
> > > On Thu, Aug 27, 2020 at 3:24 AM Liu Hao wrote:
> > > >
> > > > 在 2020/8/27 上午2:06, Vincent Torri 写道:
> > > > >
> > > > > i've checked in cmd too, same result
> > > > >
> > > > > But there is anyway something strange to me :
> > > > >
> > > > > myprog_gcc.exe and myprog_vs are *both* run in MSYS2, and the result
> > > > > is different. So I don't think it's related to path translation. It
> > > > > would suggest something related to how gcc builds the binary
> > > > >
> > > >
> > > >
> > > > In 'mingw-w64-crt/crt/crtexe.c' , `argv` is initialized by the function
> > > `__getmainargs()` which is imported from MSVCRT. VC
> > > > uses new versions of runtime libraries so it'd be MSVCR100, MSVCR120,
> > > etc. There might be some differences in the
> > > > aforementioned function.
> > >
> > > that makes sense. Is it possible to tell gcc to use msvcr*.dll instead
> > > of msvcrt.dll ?
> > >
> >
> > Asking where the difference comes from is a useful question.
> > Relying on these kinds of details to make Unicode work is not IMHO.
> >
> > If you want correct handling of unicode path names, call the appropriate
> > functions.
> > Either compile the GCC code with -municode and use _wmain, or call
> > CommandLineToArgvW with GetCommandLineW and then a _wfopen.
> > Windows is an obtuse platform, and its shells do not support the Unix-wide
> > UTF-8 assumption.
>
> I will try this, thank you
test file :
--
#include
#include
int wmain( int argc, wchar_t *argv[ ], wchar_t *envp[ ] )
{
if (argc < 2)
{
wprintf(L"%s\n", argv[0]);
return 1;
}
return 0;
}
---
but :
$ gcc -g -Wall -o fopenw fopenw.c -municode
C:/Documents/msys2/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/10.2.0/../../../../x86_64-w64-mingw32/bin/ld.exe:
C:/Documents/msys2/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/10.2.0/../../../../x86_64-w64-mingw32/lib/../lib/libmingw32.a(lib64_libmingw32_a-crt0_w.o):
in function `wmain':
D:/mingwbuild/mingw-w64-crt-git/src/mingw-w64/mingw-w64-crt/crt/crt0_w.c:23:
undefined reference to `wWinMain'
collect2.exe: error: ld returned 1 exit status
no idea what is missing, here...
Vincent Torri
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] runtime difference between code compiled with VS and gcc
On Thu, Aug 27, 2020 at 8:45 AM Ruben Van Boxem wrote: > > Op do 27 aug. 2020 om 07:18 schreef Vincent Torri : > > > On Thu, Aug 27, 2020 at 3:24 AM Liu Hao wrote: > > > > > > 在 2020/8/27 上午2:06, Vincent Torri 写道: > > > > > > > > i've checked in cmd too, same result > > > > > > > > But there is anyway something strange to me : > > > > > > > > myprog_gcc.exe and myprog_vs are *both* run in MSYS2, and the result > > > > is different. So I don't think it's related to path translation. It > > > > would suggest something related to how gcc builds the binary > > > > > > > > > > > > > In 'mingw-w64-crt/crt/crtexe.c' , `argv` is initialized by the function > > `__getmainargs()` which is imported from MSVCRT. VC > > > uses new versions of runtime libraries so it'd be MSVCR100, MSVCR120, > > etc. There might be some differences in the > > > aforementioned function. > > > > that makes sense. Is it possible to tell gcc to use msvcr*.dll instead > > of msvcrt.dll ? > > > > Asking where the difference comes from is a useful question. > Relying on these kinds of details to make Unicode work is not IMHO. > > If you want correct handling of unicode path names, call the appropriate > functions. > Either compile the GCC code with -municode and use _wmain, or call > CommandLineToArgvW with GetCommandLineW and then a _wfopen. > Windows is an obtuse platform, and its shells do not support the Unix-wide > UTF-8 assumption. I will try this, thank you Vincent Torri ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] runtime difference between code compiled with VS and gcc
Op do 27 aug. 2020 om 07:18 schreef Vincent Torri : > On Thu, Aug 27, 2020 at 3:24 AM Liu Hao wrote: > > > > 在 2020/8/27 上午2:06, Vincent Torri 写道: > > > > > > i've checked in cmd too, same result > > > > > > But there is anyway something strange to me : > > > > > > myprog_gcc.exe and myprog_vs are *both* run in MSYS2, and the result > > > is different. So I don't think it's related to path translation. It > > > would suggest something related to how gcc builds the binary > > > > > > > > > In 'mingw-w64-crt/crt/crtexe.c' , `argv` is initialized by the function > `__getmainargs()` which is imported from MSVCRT. VC > > uses new versions of runtime libraries so it'd be MSVCR100, MSVCR120, > etc. There might be some differences in the > > aforementioned function. > > that makes sense. Is it possible to tell gcc to use msvcr*.dll instead > of msvcrt.dll ? > Asking where the difference comes from is a useful question. Relying on these kinds of details to make Unicode work is not IMHO. If you want correct handling of unicode path names, call the appropriate functions. Either compile the GCC code with -municode and use _wmain, or call CommandLineToArgvW with GetCommandLineW and then a _wfopen. Windows is an obtuse platform, and its shells do not support the Unix-wide UTF-8 assumption. Relying on locally set code pages and how shells interpret them is a recipe for disaster, not to mention an incredible waste of time and effort. Ruben ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
