Hi Etienne, See http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55898 for GCC bug report. It occurs with SJLJ exception handling on x86_64. You can check by compiling with -fno-exceptions and see if it debugging works. It can be resolved by using SEH exception handling in GCC 4.8.0 which should be released soon (see http://gcc.gnu.org/ml/gcc/2013-03/msg00127.html for GCC 4.8.0 release candidate announcement).
Regards, Jonathan On 22/03/2013 7:44 PM, Etienne Sandré-Chardonnal wrote: > Actually, I suspect the compiler, since profiling with very sleepy is > also lacking caller information. Or both gdb and very sleepy are > unable to get the caller information from the executable produced by > mingw-w64. Could this be a SJLJ vs DWARF issue? My knowledge about > debugging information this is close to zero. I submitted a question to > stackoverflow some days ago without success : > http://stackoverflow.com/questions/15431754/mingw-w64-debugging-profiling-incomplete-call-stack > > Etienne > > 2013/3/22 Koehne Kai<kai.koe...@digia.com>: >>> -----Original Message----- >>> [..] >>> By the way, since you are using mingw-w64, can you debug properly >>> applications in QtCreator? When I debug programs, the call stack is empty, >>> while I still can see locals, and when I step out a function, the debugger >>> often >>> crashes. I have no such problems with the mingw32 shipped with Qt. >> I remember that gdb has issues specifically with 64 bit, but can't find the >> mail / bug report right now :( You can verify whether it's gdb or Qt Creator >> by trying to debug on the console. If it fails there too, then Qt Creator >> can do little about it. If not please create a qt-creator bug including the >> debugger log. >> >> Regards >> >> Kai _______________________________________________ Interest mailing list Interest@qt-project.org http://lists.qt-project.org/mailman/listinfo/interest
