This is the mail archive of the
libstdc++@gcc.gnu.org
mailing list for the libstdc++ project.
Re: [Ping] Port of VTV for Cygwin and MinGW
- From: Kai Tietz <ktietz70 at googlemail dot com>
- To: Patrick Wollgast <patrick dot wollgast at rub dot de>
- Cc: "cmtice at google dot com >> Caroline Tice" <cmtice at google dot com>, Benjamin De Kosnik <bkoz at gnu dot org>, "jwakely at redhat dot com >> Jonathan Wakely" <jwakely at redhat dot com>, Ian Lance Taylor <iant at google dot com>, GCC Patches <gcc-patches at gcc dot gnu dot org>, "libstdc++" <libstdc++ at gcc dot gnu dot org>
- Date: Wed, 12 Nov 2014 19:40:37 +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> <54639CC5 dot 4050508 at rub dot de>
2014-11-12 18:45 GMT+01:00 Patrick Wollgast <patrick.wollgast@rub.de>:
>>
>> 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
TerminateProcess is actually bad, as it doesn't call any of the atexit
handlers. You simply nuke the process off. For cygwin this behavior
is inacceptable. Why a classical abort, or a classical exit call
cause for you that issues? It seems to me more related to some other
thing you try to paper over by this.
> Regarding the question, why I reimplemented mprotect, I also haven't
> changed anything in the patch but answered the question.
And this doesn't make it better. It is present in the static part of
libgcc. Have you tried to declare it with extern "C" (for C++ case)
and simply use it?
Cygwin provides its own version too. So there seems to me no real
need to re-implement it.
>>> 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
Regards,
Kai