This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [Ping] Port of VTV for Cygwin and MinGW
- From: Patrick Wollgast <patrick dot wollgast at rub dot de>
- To: Kai Tietz <ktietz70 at googlemail dot com>, "cmtice at google dot com >> Caroline Tice" <cmtice at google dot com>, bkoz at gnu dot org, "jwakely at redhat dot com >> Jonathan Wakely" <jwakely at redhat dot com>, iant at google dot com
- Cc: gcc-patches at gcc dot gnu dot org, libstdc++ at gcc dot gnu dot org
- Date: Wed, 12 Nov 2014 18:45:41 +0100
- Subject: Re: [Ping] Port of VTV for Cygwin and MinGW
- Authentication-results: sourceware.org; auth=none
- References: <53FF0C8C dot 8090507 at rub dot de> <5411213F dot 1070104 at rub dot de> <CABtf2+RU7frwOXOX2FF8Tmfc6ssrpfFVj1Vuue4cZt19FpSWtQ at mail dot gmail dot com> <CABtf2+QWxvv1FUW_-kD3d0FBhYQWkZcPWAx8ASies_4j7thmoA at mail dot gmail dot com> <541B5B7E dot 2090300 at rub dot de> <20140923102235 dot GJ2669 at redhat dot com> <542344CB dot 6050600 at rub dot de> <CAEwic4b+KWO3pWQN_sbXqyf2MNWdnN8ZpaUKBVY8ECSqhe0cYg at mail dot gmail dot com> <54369316 dot 7070001 at rub dot de> <CAEwic4bT+OBQcatruiZ5Cnv1d6YMGckuf4Auf9+WzKLchNNZEg at mail dot gmail dot com> <543F9BB8 dot 1040503 at rub dot de> <54524B43 dot 7000105 at rub dot de> <5463893D dot 50807 at rub dot de> <CAEwic4YwnLjJCLii=AdG_-RXEnS3=b1nK90FA5iEsd497aRn8g at mail dot gmail dot com>
>
> I don't think you have addressed all of the comments I made in the
> comment, do you?
>
> Regards,
> Kai
>
I added the three checks, if TARGET_PECOFF is defined, and fixed the
whitespace issues.
For the questions regarding C-runtime/Win32 functions I haven't changed
anything in the patch but explained why I used those functions.
>> Why you use instead of C-runtime exit/abort-functions the
>> platform-functions to terminate the process. This looks to me like
>> useless change. For cygwin this might be even wrong in some aspects.
>> What is the reasoning for this change?
>>
>
> I haven't encountered crashes in obstack.c itself, but there were
> problems in vtv_rts.cc with abort() on MinGW 32bit. The following stack
> traces were taken at MinGW 32bit. Most of the time the process had to be
> stopped in the process manager because a wrong process handle was passed
> to NtTerminateProcess. This was tested and occurred on Windows 7 64bit
> and Windows 8.1 64bit. To be sure to avoid this issue the calls have
> also been exchanged in obstack.c.
>
> With abort(), correct process handle, postmortem debugger triggert.
>
> ffffffff 00000003 0028fe98 ntdll!NtTerminateProcess+0xc
> 00000003 77e8f3b0 ffffffff ntdll!RtlExitUserProcess+0x6d
> 00000003 0028f934 74f85472 KERNEL32!ExitProcessImplementation+0x12
> 00000003 11e9bfd9 00409000 msvcrt!exit+0x32
> 00000003 00000001 00000000 msvcrt!flushall+0x2e9
> 00000003 00010001 00000065 msvcrt!exit+0x11
> 6efcf294 00000080 0028ffcc msvcrt!abort+0xf3
> 00560f70 0000000d 00000001 libvtv_0!Z14__fortify_failPKc+0x18
> 7ffde000 0028ffdc 77568f8b test_std+0x13de
> 7ffde000 138a1dee 00000000 KERNEL32!BaseThreadInitThunk+0xe
> ffffffff 7755dad3 00000000 ntdll!__RtlUserThreadStart+0x20
> 004014e0 7ffde000 00000000 ntdll!_RtlUserThreadStart+0x1b
>
> With abort(), wrong process handle, NtTerminateProcess returns instead
> of ending the own process. This case happens most of the time.
>
> 00000000 00000003 0028fe98 ntdll!NtTerminateProcess+0x5
> 00000003 77e8f3b0 ffffffff ntdll!RtlExitUserProcess+0x35
> 00000003 0028f934 74f85472 KERNEL32!ExitProcessImplementation+0x12
> 00000003 9f9f5ea3 00409000 msvcrt!exit+0x32
> 00000003 00000001 00000000 msvcrt!flushall+0x2e9
> 00000003 00010001 00000040 msvcrt!exit+0x11
> 6efcf294 00000080 0028ffcc msvcrt!abort+0xf3
> 00701060 0000001e 00000001 libvtv_0!Z14__fortify_failPKc+0x18
> 7ffde000 0028ffdc 77568f8b image00400000+0x13de
> 7ffde000 9defd39c 00000000 KERNEL32!BaseThreadInitThunk+0xe
> ffffffff 7755dac5 00000000 ntdll!__RtlUserThreadStart+0x20
> 004014e0 7ffde000 00000000 ntdll!_RtlUserThreadStart+0x1b
>
> TerminateProcess. Everything's fine on MinGW x86, x86-64 (both gcc 5.0),
> Cygwin x86-64 (gcc 4.9.0).
>
> ffffffff 0000022f 0028feb8 ntdll!NtTerminateProcess+0x5
> ffffffff 0000022f 00409000 KERNELBASE!TerminateProcess+0x27
> 00731060 0000001e 00000001 libvtv_0!Z14__fortify_failPKc+0x2a
> 7ffde000 0028ffdc 77568f8b image00400000+0x13de
> 7ffde000 e2645ec6 00000000 KERNEL32!BaseThreadInitThunk+0xe
> ffffffff 7755dae7 00000000 ntdll!__RtlUserThreadStart+0x20
> 004014e0 7ffde000 00000000 ntdll!_RtlUserThreadStart+0x1b
Regarding the question, why I reimplemented mprotect, I also haven't
changed anything in the patch but answered the question.
>> Another note I have about re-implementation of mprotect in ---
>> libvtv/vtv_malloc.cc. Why you need that? it is already part of
>> libgcc for mingw. And for cygwin this function is part of cygwin's
>> library itself. So why re-implementing it here?
>>
>
> It is already part of libgcc for MinGW, but it can neither be found in
> the exports of the dll, nor can the function prototype be found in any
> header files. Therefore I get unknown reference errors if I don't
> re-implement it. I checked the exports of several compilations for this.
>
> * self compiled MinGW
> * MinGW installed from the Arch Linux repositories
> *
>
http://sourceforge.net/projects/mingw-w64/files/Toolchains%20targetting%20Win64/Automated%20Builds/mingw-w64-bin_x86_64-linux_20131228.tar.bz2/download
>
> If I'm missing something here let me know.
I think this was everything you addressed.
Regards,
Patrick