Re: [Mingw-w64-public] [PATCH 1/2] crt: Use importlib for _assert.
On Fri, 17 May 2019, Martin Storsjö wrote: Backtracking to the original user's report, his issue is that gdb doesn't manage to backtrace out from ucrtbase.dll, but now it does seem to work just fine for me. It turned out that the original reporter's issue was in his own setup, there's no other issue here, other than the _set_app_type mixup. // Martin ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] [PATCH 1/2] crt: Use importlib for _assert.
On Fri, 17 May 2019, Jacek Caban wrote:
On 5/17/19 10:11 PM, Martin Storsjö wrote:
On Fri, 17 May 2019, Jacek Caban wrote:
I see it now. The problem seems to be wider than assert and caused by
__set_app_type call in ucrtbase_main.c. If I remove them, it behaves
correctly. Do you remember it's called there? Note that crtexe.c already
sets app type correctly, but it's broken by __getmainargs later.
I think the reason why I added the __set_app_type call in __getmainargs, is
that I checked with the wine implementation of the function for hints about
what it should do, when implementing this for the ucrt compat wrapping.
Wine's function looks like this:
int CDECL __getmainargs(int *argc, char** *argv, char** *envp,
int expand_wildcards, int *new_mode)
{
...
if (new_mode)
MSVCRT__set_new_mode( *new_mode );
return 0;
}
But now when looking at the mingw-w64 crt code, I see that *new_mode always
is 0 here - so apparently msvcrt.dll doesn't actually use the parameter in
this exact way.
new_mode seems to be something different than app type and we could probably
use _set_new_mode for that, but we should be fine ignoring it.
Oh, I somehow have misread this all the time, I read MSVCRT__set_new_mode
as MSVCRT__set_app_type.
Well then it's exceptionally clear.
I tried including new.h and calling _set_new_mode(), but apparently all of
new.h is hidden behind an #ifdef __cplusplus, so the current declaration
isn't visible to be called from C code.
// Martin
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] [PATCH 1/2] crt: Use importlib for _assert.
On 5/17/19 10:11 PM, Martin Storsjö wrote:
On Fri, 17 May 2019, Jacek Caban wrote:
I see it now. The problem seems to be wider than assert and caused by
__set_app_type call in ucrtbase_main.c. If I remove them, it behaves
correctly. Do you remember it's called there? Note that crtexe.c already
sets app type correctly, but it's broken by __getmainargs later.
I think the reason why I added the __set_app_type call in
__getmainargs, is that I checked with the wine implementation of the
function for hints about what it should do, when implementing this for
the ucrt compat wrapping.
Wine's function looks like this:
int CDECL __getmainargs(int *argc, char** *argv, char** *envp,
int expand_wildcards, int *new_mode)
{
...
if (new_mode)
MSVCRT__set_new_mode( *new_mode );
return 0;
}
But now when looking at the mingw-w64 crt code, I see that *new_mode
always is 0 here - so apparently msvcrt.dll doesn't actually use the
parameter in this exact way.
new_mode seems to be something different than app type and we could
probably use _set_new_mode for that, but we should be fine ignoring it.
Jacek
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] [PATCH 1/2] crt: Use importlib for _assert.
On Fri, 17 May 2019, Jacek Caban wrote:
I see it now. The problem seems to be wider than assert and caused by
__set_app_type call in ucrtbase_main.c. If I remove them, it behaves
correctly. Do you remember it's called there? Note that crtexe.c already
sets app type correctly, but it's broken by __getmainargs later.
I think the reason why I added the __set_app_type call in __getmainargs,
is that I checked with the wine implementation of the function for hints
about what it should do, when implementing this for the ucrt compat
wrapping.
Wine's function looks like this:
int CDECL __getmainargs(int *argc, char** *argv, char** *envp,
int expand_wildcards, int *new_mode)
{
...
if (new_mode)
MSVCRT__set_new_mode( *new_mode );
return 0;
}
But now when looking at the mingw-w64 crt code, I see that *new_mode
always is 0 here - so apparently msvcrt.dll doesn't actually use the
parameter in this exact way.
// Martin
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] [PATCH 1/2] crt: Use importlib for _assert.
On 5/17/19 10:02 PM, Jacek Caban wrote: The problem seems to be wider than assert and caused by __set_app_type call in ucrtbase_main.c. I obviously meant ucrtbase_compat.c. Jacek ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] [PATCH 1/2] crt: Use importlib for _assert.
On 5/17/19 9:21 PM, Martin Storsjö wrote: On Fri, 17 May 2019, Jacek Caban wrote: On 5/17/19 10:44 AM, Martin Storsjö wrote: On Fri, 29 Mar 2019, Jacek Caban wrote: On 3/29/19 8:26 PM, Martin Storsjö wrote: On Fri, 29 Mar 2019, Jacek Caban wrote: Signed-off-by: Jacek Caban --- mingw-w64-crt/Makefile.am | 2 +- .../api-ms-win-crt-runtime-l1-1-0.def.in | 2 +- mingw-w64-crt/lib-common/msvcrt.def.in | 2 +- mingw-w64-crt/lib-common/ucrtbase.def.in | 2 +- mingw-w64-crt/lib32/msvcr100.def.in | 2 +- mingw-w64-crt/lib32/msvcr80.def.in | 2 +- mingw-w64-crt/lib32/msvcr90.def.in | 2 +- mingw-w64-crt/lib32/msvcr90d.def.in | 2 +- mingw-w64-crt/lib64/msvcr100.def.in | 2 +- mingw-w64-crt/lib64/msvcr80.def.in | 2 +- mingw-w64-crt/lib64/msvcr90.def.in | 2 +- mingw-w64-crt/lib64/msvcr90d.def.in | 2 +- mingw-w64-crt/misc/assert.c | 31 --- mingw-w64-headers/crt/assert.h | 3 +- 14 files changed, 13 insertions(+), 45 deletions(-) delete mode 100644 mingw-w64-crt/misc/assert.c LGTM (Do you happen to know why this was this way to begin with? It seems to me that this function existed even already in win2k.) I don't know, maybe win9x? It has been in the tree since "Add initial snapshot of runtime crt." commit and I didn't dig in mingw.org history. It turned out that this had some other consequences. If debugging an app with gdb, one could previously catch those asserts in gdb and do meaningful debugging around them (according to the reporter). Now, asserts trigger the msvcrt's assertion failure dialog, which doesn't really seem to interact quite as well with gdb. Previously, a console exe would exit cleanly within gdb on assertion failures, but putting a breakpoint on "abort" seems to stop at a good point. A GUI exe opens a dialog box, but I can't seem to be able to catch the abort in gdb in that case. (Does anyone have better insight into how to catch it better?) Now when using the msvcrt's assert, even console exes pop up the dialog, and catching the abort from there doesn't seem to work. That's not what I see. I remember testing that previously and just confirmed that -mconsole/-mwindows switch works and assert uses console or window depending on it. Right, this seems to be a msvcrt vs ucrt difference; with ucrt, it always uses a window. I see it now. The problem seems to be wider than assert and caused by __set_app_type call in ucrtbase_main.c. If I remove them, it behaves correctly. Do you remember it's called there? Note that crtexe.c already sets app type correctly, but it's broken by __getmainargs later. Jacek ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] [PATCH 1/2] crt: Use importlib for _assert.
On Fri, 17 May 2019, Jacek Caban wrote: On 5/17/19 10:44 AM, Martin Storsjö wrote: On Fri, 29 Mar 2019, Jacek Caban wrote: On 3/29/19 8:26 PM, Martin Storsjö wrote: On Fri, 29 Mar 2019, Jacek Caban wrote: Signed-off-by: Jacek Caban --- mingw-w64-crt/Makefile.am | 2 +- .../api-ms-win-crt-runtime-l1-1-0.def.in | 2 +- mingw-w64-crt/lib-common/msvcrt.def.in | 2 +- mingw-w64-crt/lib-common/ucrtbase.def.in | 2 +- mingw-w64-crt/lib32/msvcr100.def.in | 2 +- mingw-w64-crt/lib32/msvcr80.def.in | 2 +- mingw-w64-crt/lib32/msvcr90.def.in | 2 +- mingw-w64-crt/lib32/msvcr90d.def.in | 2 +- mingw-w64-crt/lib64/msvcr100.def.in | 2 +- mingw-w64-crt/lib64/msvcr80.def.in | 2 +- mingw-w64-crt/lib64/msvcr90.def.in | 2 +- mingw-w64-crt/lib64/msvcr90d.def.in | 2 +- mingw-w64-crt/misc/assert.c | 31 --- mingw-w64-headers/crt/assert.h | 3 +- 14 files changed, 13 insertions(+), 45 deletions(-) delete mode 100644 mingw-w64-crt/misc/assert.c LGTM (Do you happen to know why this was this way to begin with? It seems to me that this function existed even already in win2k.) I don't know, maybe win9x? It has been in the tree since "Add initial snapshot of runtime crt." commit and I didn't dig in mingw.org history. It turned out that this had some other consequences. If debugging an app with gdb, one could previously catch those asserts in gdb and do meaningful debugging around them (according to the reporter). Now, asserts trigger the msvcrt's assertion failure dialog, which doesn't really seem to interact quite as well with gdb. Previously, a console exe would exit cleanly within gdb on assertion failures, but putting a breakpoint on "abort" seems to stop at a good point. A GUI exe opens a dialog box, but I can't seem to be able to catch the abort in gdb in that case. (Does anyone have better insight into how to catch it better?) Now when using the msvcrt's assert, even console exes pop up the dialog, and catching the abort from there doesn't seem to work. That's not what I see. I remember testing that previously and just confirmed that -mconsole/-mwindows switch works and assert uses console or window depending on it. Right, this seems to be a msvcrt vs ucrt difference; with ucrt, it always uses a window. If I get the dialog and click 'retry' button, it issues a break point that is properly handled by DBG. If I choose 'break', the application quits using abort() and if I set breakpoint there, it's triggered. Same for console case, a breakpoint in abort() is hit. Hmm, yes, that does seem to work after giving it another look. Backtracking to the original user's report, his issue is that gdb doesn't manage to backtrace out from ucrtbase.dll, but now it does seem to work just fine for me. // Martin ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] [PATCH 1/2] crt: Use importlib for _assert.
On 5/17/19 10:44 AM, Martin Storsjö wrote: On Fri, 29 Mar 2019, Jacek Caban wrote: On 3/29/19 8:26 PM, Martin Storsjö wrote: On Fri, 29 Mar 2019, Jacek Caban wrote: Signed-off-by: Jacek Caban --- mingw-w64-crt/Makefile.am | 2 +- .../api-ms-win-crt-runtime-l1-1-0.def.in | 2 +- mingw-w64-crt/lib-common/msvcrt.def.in | 2 +- mingw-w64-crt/lib-common/ucrtbase.def.in | 2 +- mingw-w64-crt/lib32/msvcr100.def.in | 2 +- mingw-w64-crt/lib32/msvcr80.def.in | 2 +- mingw-w64-crt/lib32/msvcr90.def.in | 2 +- mingw-w64-crt/lib32/msvcr90d.def.in | 2 +- mingw-w64-crt/lib64/msvcr100.def.in | 2 +- mingw-w64-crt/lib64/msvcr80.def.in | 2 +- mingw-w64-crt/lib64/msvcr90.def.in | 2 +- mingw-w64-crt/lib64/msvcr90d.def.in | 2 +- mingw-w64-crt/misc/assert.c | 31 --- mingw-w64-headers/crt/assert.h | 3 +- 14 files changed, 13 insertions(+), 45 deletions(-) delete mode 100644 mingw-w64-crt/misc/assert.c LGTM (Do you happen to know why this was this way to begin with? It seems to me that this function existed even already in win2k.) I don't know, maybe win9x? It has been in the tree since "Add initial snapshot of runtime crt." commit and I didn't dig in mingw.org history. It turned out that this had some other consequences. If debugging an app with gdb, one could previously catch those asserts in gdb and do meaningful debugging around them (according to the reporter). Now, asserts trigger the msvcrt's assertion failure dialog, which doesn't really seem to interact quite as well with gdb. Previously, a console exe would exit cleanly within gdb on assertion failures, but putting a breakpoint on "abort" seems to stop at a good point. A GUI exe opens a dialog box, but I can't seem to be able to catch the abort in gdb in that case. (Does anyone have better insight into how to catch it better?) Now when using the msvcrt's assert, even console exes pop up the dialog, and catching the abort from there doesn't seem to work. That's not what I see. I remember testing that previously and just confirmed that -mconsole/-mwindows switch works and assert uses console or window depending on it. If I get the dialog and click 'retry' button, it issues a break point that is properly handled by DBG. If I choose 'break', the application quits using abort() and if I set breakpoint there, it's triggered. Same for console case, a breakpoint in abort() is hit. I also tried to set SIGABRT handler that emits breakpoint in the test application itself. In such setting breakpoint in gdb is not needed. Thanks, Jacek ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] [PATCH 1/2] crt: Use importlib for _assert.
On Fri, 29 Mar 2019, Jacek Caban wrote: On 3/29/19 8:26 PM, Martin Storsjö wrote: On Fri, 29 Mar 2019, Jacek Caban wrote: Signed-off-by: Jacek Caban --- mingw-w64-crt/Makefile.am | 2 +- .../api-ms-win-crt-runtime-l1-1-0.def.in | 2 +- mingw-w64-crt/lib-common/msvcrt.def.in | 2 +- mingw-w64-crt/lib-common/ucrtbase.def.in | 2 +- mingw-w64-crt/lib32/msvcr100.def.in | 2 +- mingw-w64-crt/lib32/msvcr80.def.in | 2 +- mingw-w64-crt/lib32/msvcr90.def.in | 2 +- mingw-w64-crt/lib32/msvcr90d.def.in | 2 +- mingw-w64-crt/lib64/msvcr100.def.in | 2 +- mingw-w64-crt/lib64/msvcr80.def.in | 2 +- mingw-w64-crt/lib64/msvcr90.def.in | 2 +- mingw-w64-crt/lib64/msvcr90d.def.in | 2 +- mingw-w64-crt/misc/assert.c | 31 --- mingw-w64-headers/crt/assert.h | 3 +- 14 files changed, 13 insertions(+), 45 deletions(-) delete mode 100644 mingw-w64-crt/misc/assert.c LGTM (Do you happen to know why this was this way to begin with? It seems to me that this function existed even already in win2k.) I don't know, maybe win9x? It has been in the tree since "Add initial snapshot of runtime crt." commit and I didn't dig in mingw.org history. It turned out that this had some other consequences. If debugging an app with gdb, one could previously catch those asserts in gdb and do meaningful debugging around them (according to the reporter). Now, asserts trigger the msvcrt's assertion failure dialog, which doesn't really seem to interact quite as well with gdb. Previously, a console exe would exit cleanly within gdb on assertion failures, but putting a breakpoint on "abort" seems to stop at a good point. A GUI exe opens a dialog box, but I can't seem to be able to catch the abort in gdb in that case. (Does anyone have better insight into how to catch it better?) Now when using the msvcrt's assert, even console exes pop up the dialog, and catching the abort from there doesn't seem to work. // Martin ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] [PATCH 1/2] crt: Use importlib for _assert.
On 3/29/19 8:26 PM, Martin Storsjö wrote: On Fri, 29 Mar 2019, Jacek Caban wrote: Signed-off-by: Jacek Caban --- mingw-w64-crt/Makefile.am | 2 +- .../api-ms-win-crt-runtime-l1-1-0.def.in | 2 +- mingw-w64-crt/lib-common/msvcrt.def.in | 2 +- mingw-w64-crt/lib-common/ucrtbase.def.in | 2 +- mingw-w64-crt/lib32/msvcr100.def.in | 2 +- mingw-w64-crt/lib32/msvcr80.def.in | 2 +- mingw-w64-crt/lib32/msvcr90.def.in | 2 +- mingw-w64-crt/lib32/msvcr90d.def.in | 2 +- mingw-w64-crt/lib64/msvcr100.def.in | 2 +- mingw-w64-crt/lib64/msvcr80.def.in | 2 +- mingw-w64-crt/lib64/msvcr90.def.in | 2 +- mingw-w64-crt/lib64/msvcr90d.def.in | 2 +- mingw-w64-crt/misc/assert.c | 31 --- mingw-w64-headers/crt/assert.h | 3 +- 14 files changed, 13 insertions(+), 45 deletions(-) delete mode 100644 mingw-w64-crt/misc/assert.c LGTM (Do you happen to know why this was this way to begin with? It seems to me that this function existed even already in win2k.) I don't know, maybe win9x? It has been in the tree since "Add initial snapshot of runtime crt." commit and I didn't dig in mingw.org history. Thanks for the review, Jacek ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] [PATCH 1/2] crt: Use importlib for _assert.
On 3/29/19 7:47 PM, Martin Storsjö wrote: On Fri, 29 Mar 2019, Jacek Caban wrote: Signed-off-by: Jacek Caban --- mingw-w64-crt/Makefile.am | 2 +- mingw-w64-crt/misc/assert.c | 31 --- mingw-w64-headers/crt/assert.h | 3 +-- 3 files changed, 2 insertions(+), 34 deletions(-) delete mode 100644 mingw-w64-crt/misc/assert.c Shouldn't we remove the DATA markings for _assert in all the crt def files here as well? Yeah, good catch, I had it in another commit accidentally. I will send a new version. Thanks, Jacek ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] [PATCH 1/2] crt: Use importlib for _assert.
On Fri, 29 Mar 2019, Jacek Caban wrote: Signed-off-by: Jacek Caban --- mingw-w64-crt/Makefile.am | 2 +- mingw-w64-crt/misc/assert.c| 31 --- mingw-w64-headers/crt/assert.h | 3 +-- 3 files changed, 2 insertions(+), 34 deletions(-) delete mode 100644 mingw-w64-crt/misc/assert.c Shouldn't we remove the DATA markings for _assert in all the crt def files here as well? // Martin ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
