I've got the latest versions of codeblocks on my linux and windoze7 computers, with the latest version of TDM-GCC mingw64 (tdm64-gcc-461) from this webpage:
http://tdm-gcc.tdragon.net/download. For most of my applications, I defined the following targets:
linux32_debug
linux32_release
linux64_debug
linux64_release
windoze32_debug
windoze32_release
windoze64_debug
windoze64_release
To keep everything separate, and avoid unwanted interactions, all targets create separate directories with those same names to store their object files and executable. For example: linux32_debug for object files and linux32_debug/bin for the executable.
The 32-bit and 64-bit versions of my applications now build fine on linux. The 64-bit versions of applications also usually build and execute okay on windoze7. The 32-bit versions of applications also build on windoze7, but... I cannot debug them.
Here is what happens when I create a simplistic "hello world" application with one main() function and only 3 printf() statements (more than one printf() so I can try to perform debug steps like "run-to-cursor", "single-step", etc). I build=>clean, then build=>build. The build process completes, though it prints out a couple dozen almost identical messages like the following:
c:/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/4.6.1/../../../../x86_64-w64-mingw32/bin/ld.exe:
skipping incompatible \mingw64\x86_64-w64-mingw32\lib\libmsvcrt.a when searching for -lmsvcrt
The only difference between the messages is the "libmsvcrt.a" part, which cycles through all sorts of files.
However, at the end, the compilation process claims to have completed with zero errors and zero warnings.
When I try to run "to-cursor" to the second printf() line, the console window appears and it contains the output from the first printf() line. However, everything else is "busted". Here's what I mean:
#1: The yellow right-arrow that indicates "stopped-at-this-line" does not exist.
#2: The "cpu register" window does contain register values, but the values appear to be totally bogus.
#3: The "disassembly" window is empty, and the labels say "function: ??" and "frame start: ??".
#4: The "call stack" window says:
- nr = 0
- address = 0008DC18
- function = ?? ()
- file = <empty>
- line = <empty>
#5: The "debugger tab" window says:
- debugger name and version GNU GDB (gdb) 7.3.1
- child process PID: 4668
- in ?? () ()
- failure finding "Stack level "
- failure matching reg_output
Given that the ebp register == 0x00000000, it is not surprising the debugger is having problems figuring out where the stack is (probably because it is getting the register values from the wrong place... or something). And when I look at the memory at the eip register address (0x0008DC18), I see mostly 0x00 bytes with scattered data-looking values (groups of 4 non-zero bytes all aligned on mod-4 addresses), not opcode values. Oddly though, at the displayed rip register address (0x004F3EEF), I see what might be code in the memory window. I'm not sure how to make the disassembler disassemble those addresses to see for sure whether that is code --- it could be. However, when I try to display memory at ANY of the other addresses in the 64-bit register values, the memory window cannot display those memory areas, which makes me suspicious that any of the 64-bit registers mean anything at all, rip included.
Also, once a breakpoint is hit once, "nothing else works". Sometimes I can kill the program by clicking the square red "x" mark button on the codeblocks "debugger" menu bar (with the run-to, single-step, step-in, step-out, buttons). However, other times codeblocks goes "clueless" and I have to force codeblocks to close to recover.
This is probably "my fault", and probably somewhere in the mountains of documents is something that would have prevented me from making whatever mistake I'm making. The symptoms are a bit strange. Obviously the program is hitting the debugger at the "run-to" line in the source code, because only the printf() statements before that line are executed. Yet the registers and everything else are completely screwed up.
If I had to guess, I'd say "somehow" codeblocks is successfully linking my code to incorrect libraries, maybe even 64-bit libraries. But hey, that's only a guess. But I do suspect I need some switch or something in the 32-bit targets to make these problems go away. Or maybe I need to add a search path.
One thing I don't have wrong: I have -m32 and -m64 switches to both compiler and linker in every target. I have noticed it creates 64-bit executables when the -m32 switch is not given.
Ideas, anyone?
