Unable to debug UNICODE exe

[ssawgift]

I have a very simple test project. I have UNICODE;_UNICODE; defines in Preprocessors in Project Settings dialog and -municode in linker options. My compiler suite is MinGW64 (64-bit MinGW). With these settings, I am not able to debug the output exe. If I remove UNICODE;_UNICODE; defines, then everything works fine.

I once reported this problem as a ticket on github. Someone replied to me that he was very certain it's a problem of gdb itself. But I don't think that way. Proof is that I have a CodeBlocks project that have exact same source files as CodeLite project and I am able to debug UNICODE output exe.

I also tried the older version 4.9.3 of MinGW64 with CodeLite, but that does not make difference on UNICODE build.

Any suggestions will be appreciated.

BTW, my GCC -v output below:
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=C:/Programs/gnu/mingw64/bin/../libexec/gcc/x86_64-w64-mingw32/5.3.0/lto-wrapper.exe
Target: x86_64-w64-mingw32
Configured with: ../../../src/gcc-5.3.0/configure --host=x86_64-w64-mingw32 --build=x86_64-w64-mingw32 --target=x86_64-w64-mingw32 --prefix=/mingw64 --with-sysroot=/c/mingw530/x86_64-530-win32-seh-rt_v4-rev0/mingw64 --with-gxx-include-dir=/mingw64/x86_64-w64-mingw32/include/c++ --enable-shared --enable-static --disable-multilib --enable-languages=c,c++,fortran,lto --enable-libstdcxx-time=yes --enable-threads=win32 --enable-libgomp --enable-libatomic --enable-lto --enable-graphite --enable-checking=release --enable-fully-dynamic-string --enable-version-specific-runtime-libs --disable-isl-version-check --disable-libstdcxx-pch --disable-libstdcxx-debug --enable-bootstrap --disable-rpath --disable-win32-registry --disable-nls --disable-werror --disable-symvers --with-gnu-as --with-gnu-ld --with-arch=nocona --with-tune=core2 --with-libiconv --with-system-zlib --with-gmp=/c/mingw530/prerequisites/x86_64-w64-mingw32-static --with-mpfr=/c/mingw530/prerequisites/x86_64-w64-mingw32-static --with-mpc=/c/mingw530/prerequisites/x86_64-w64-mingw32-static --with-isl=/c/mingw530/prerequisites/x86_64-w64-mingw32-static --with-pkgversion='x86_64-win32-seh-rev0, Built by MinGW-W64 project' --with-bugurl=http://sourceforge.net/projects/mingw-w64 CFLAGS='-O2 -pipe -I/c/mingw530/x86_64-530-win32-seh-rt_v4-rev0/mingw64/opt/include -I/c/mingw530/prerequisites/x86_64-zlib-static/include -I/c/mingw530/prerequisites/x86_64-w64-mingw32-static/include' CXXFLAGS='-O2 -pipe -I/c/mingw530/x86_64-530-win32-seh-rt_v4-rev0/mingw64/opt/include -I/c/mingw530/prerequisites/x86_64-zlib-static/include -I/c/mingw530/prerequisites/x86_64-w64-mingw32-static/include' CPPFLAGS= LDFLAGS='-pipe -L/c/mingw530/x86_64-530-win32-seh-rt_v4-rev0/mingw64/opt/lib -L/c/mingw530/prerequisites/x86_64-zlib-static/lib -L/c/mingw530/prerequisites/x86_64-w64-mingw32-static/lib '
Thread model: win32
gcc version 5.3.0 (x86_64-win32-seh-rev0, Built by MinGW-W64 project)

[eranif]

But I don't think that way. Proof is that I have a CodeBlocks project that have exact same source files as CodeLite project and I am able to debug UNICODE output exe

CodeLite and CodeBlocks are not using the same GDB interface (CL uses MI while CB uses annotations) so unless you are able to provide a simple workspace (with a minimal source file) that demonstrates the problem I am afraid no one will be able to help you

With these settings, I am not able to debug the output exe

This sentence has 0 information in it, I could argue, that "it works", again it won't help you - but it contains the exact same of information that you provided

Note that CodeLite itself is built with UNICODE enabled and is debugged using CodeLite itself without any issues (on Windows, with TDM-GCC 4.9.3/64bit)

Eran

[ssawgift]

With these settings, I am not able to debug the output exe

This sentence has 0 information in it, I could argue, that "it works", again it won't help you - but it contains the exact same of information that you provided

Note that CodeLite itself is built with UNICODE enabled and is debugged using CodeLite itself without any issues (on Windows, with TDM-GCC 4.9.3/64bit)

Eran

I'm not a native Engish speaker so I'm not able to express my problem efficiently. If you read "If I remove UNICODE;_UNICODE; defines, then everything works fine." I think my original post at least conveyed that with different settings (key is UNICODE define) CL has a problem with debugging.

And my first post serves as just a starting point. I will sure eventually provide more information, as I do now. I'm attaching my simple project as it is so that you can find out what's wrong.

[ssawgift]

Any update on this issue yet?

[eranif]

Yes, your sample workspace does not compile on Windows/TDM-GCC-64 bit 4.9.3
So I could not test this

Eran

[ssawgift]

Yes, your sample workspace does not compile on Windows/TDM-GCC-64 bit 4.9.3
So I could not test this

Eran

I think you could just comment out error code lines because most of the code is not useful. The key to this problem is to get the project compiled (even a single line of code will do) and try if debugging works.

BTW, I tried to download TDM-GCC 4.9.3 (https://sourceforge.net/projects/tdm-gc ... 0Releases/), but don't know why they removed 4.9.3 releases. I only see 4.8.3.

[ssawgift]

I see the weekly build 9.1.8 has an improvement on this issue. Instead of silent failure, CL now gives me an error message:

Debugger exited with the following error string:
"Error creating process D:\\Build\\git\\lab\\applets\\test\\cpptest\\bin\\Debug\\test.exe, (error 5)."

It's really strange gdb fails on this completely normal EXE file. I remember once I could debug this EXE using commandline gdb.