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 <ja...@codeweavers.com>
---
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

Reply via email to