User forums > Using Code::Blocks

Using CodeBlocks to debug itself.

(1/2) > >>

everSome:
Having used CodeBlocks to build a nightly debug version of CodeBlocks, how do I use CodeBlocks's debugging capabilites to Step into CodeBlocks as a way to learn about CodeBlocks internals. I'm doing this on Windows 10 using a MSYS2 environment. I've come to grips with the build process, without understanding really how to use CodeBlocks. I'm guessing this sounds rather strange, but such is life. Having CodeBlocks nightly to build itself at least works to this extent, but I haven't used the various plugins. So far I've used the mingw64 and ucrt64 compiler tool chains to build nightlies to then build themselves. I've downloaded the clang64 compiler package, but haven't tried it yet, but as it lays claim to being gcc compatible, it should/can be made to work also. To build a debug version, I set cb_release_type to -Og. Is the main code in src/src? Help! A shout out to AndrewCot and his Unofficial Code::Blocks Installers which got me up and running.

AndrewCot:
I have been working on a bunch of doc updates. Have a read of the attached work in progress doc that has the info and process for using C::B to debug C::B.

It sounds like you have built C::B, but as you did not specify how, I would start at step 2 in the "To build Code::Blocks:" section as this will ensure you build C::B with all of the plugins etc.
This is my notes for how I configure the cb_release_type environment variables:
   BASE:  -g -O0 -ggdb
   Under the User Defined area add build and set it to debug

As for how C::B internally works head on over to the wiki site, https://wiki.codeblocks.org/index.php/Main_Page , and have a good read (*** some pages are way out of date, so be careful if it mentions C::B V1 I would not read it as it is way out of date).

BlueHazzard:
The most important thing to debug codeblocks with codeblocks is to add the -g in the global variable as AndrewCot pointed out,
then it should simply work by hitting the debug button for the src target

One thing is also to build wxWidgets with debug symbols, this helps a lot by finding problems.

Also look at the gdb version 8.x has some problems

everSome:
As to what I've done, I ended up throwing a nightly into Mercurial to monitor what I found necessary to change, and then just export those changes and then import them into the next nightly I want to compile. Using CodeBlocks_wx31_64.cbp  on my windows 10 system with only MSYS2 installed has problems. First windows, at least on my system, doesn't have zip or strip, and the xcopy that it does have takes its options after arguments, not before them. For xcopy, some places I've replaced it with cp, but in other places I repositioned the options to the end of that xcopy command and let window deal with it.   MSYS2 does provide versions of zip and strip, as well as a unix type mkdir that can be used to replace windows md and mkdir. While one can hardcode where these various parts reside (which is what I did initially), it is better to let MSYS2 decide where they are. I've come to understand that MSYS2, being a Cygwin fork, has it's Cygwin executable components in

C:\msys64\usr\bin,
and it's native components in
C:\msys64\ucrt64\bin, C:\msys64\mingw64\bin, etc.

The trick is to pass everything intended for MSYS2 through a MSYS2 login bash shell. To do this I'm using two custom variables which I define for each of the MSYS2 compilers I want to use be it gcc-msys2-mingw64, gcc-msys2-ucrt64, etc. The last one of course is my own creation. For that matter I've made compiler_... and options_... for clang64 as well. Rather arbitrarily, I've called them MSC and MSD. The value of these keys are what is within the the following quotes but does not include them, namely

"$(TARGET_COMPILER_DIR)..\usr\bin\env MSYSTEM=UCRT64 CHERE_INVOKING=1 /usr/bin/bash -lc '"
"$(TARGET_COMPILER_DIR)..\usr\bin\env MSYSTEM=MINGW64 CHERE_INVOKING=1 /usr/bin/bash -lc '"
"$(TARGET_COMPILER_DIR)..\usr\bin\env MSYSTEM=CLANG64 CHERE_INVOKING=1 /usr/bin/bash -lc '"
The value for  the key MSD is just "'".

This makes things like the following work:
<Add after="$(MSC)mkdir -p devel31_64/share/CodeBlocks$(MSD)" />
<Add after="$(MSC)./update.bash 31_64$(MSD)" />

The caveat being you can only use double quotes here because single quotes are used in the MSC and MSD compiler variables to denote the command being sent to bash.

The CHERE_INVOKING=1 variable keeps bash from changing  the current working directory to your login
directory, and the value of MSYSTEM tells bash which native subsystem to look in first before resorting to /usr/bin, or then windows. The appropriate values for MSYSTEM can be found in the file:
C:\msys64\msys2_shell.cmd
of a typical MSYS2 installation.

I would have liked to have found a way to define these MSC and MSD compiler variables in the compiler_... options... files, but have only found them to be saved in your AppData\Roaming\CodeBlocks\default.conf and then loaded therefrom or specified through the CodeBlocks UI.

Note that I've avoided changing the surrounding environment as little as possible. Thus the "./update.bash" rather than "update.bash" as that would require one to change their PATH definition to include the current directory. I've not mentioned it, but I have within the "Debugger settings" window created Configurations for each of the MSYS2 compilers named with the ID for that compiler and set the executable path within that configuration to something like "C:\msys64\mingw64\bin\gdb.exe", etc., and then in the "Compiler settings" window, in the "Program Files" subtab of the "ToolChains executable" tab, set the "Debugger" selection to the appropriate Debugger configuration that I just created, for instance:
"GDB/CDB debugger: gcc-msys2-mingw64"
sans the quotation marks.

Not liking to have to depend on defaults, I personally run the following in a MSYS2 terminal window,

cd CodeBlocks/codeblocks-code-r12661-trunk/src
find . -name '*31_64.cbp' -exec sed -i 's/compiler="gcc"/compiler="gcc-msys2-ucrt64"/' {} \;

But setting one of the MSYS2 compilers to be the default compiler should also work.

Now that I'm sending all the MSYS2 stuff through bash, I should try putting the Reverse Solidus (aka backslash)
back in to see if bash will convert them to unix style file paths required by the MSYS2 command .exe files.

everSome:

--- Quote from: BlueHazzard on January 21, 2022, 02:02:15 pm ---The most important thing to debug codeblocks with codeblocks is to add the -g in the global variable as AndrewCot pointed out,
then it should simply work by hitting the debug button for the src target

One thing is also to build wxWidgets with debug symbols, this helps a lot by finding problems.

Also look at the gdb version 8.x has some problems

--- End quote ---

OK, I thin I understand what you are telling me. I did set cb_release_type to -Og as recommended by gcc documentation, and recompiled CodeBlocks and ContribPlugins, but left wxWidgets compiled -O3. I have the compiler set to gcc-msys2-ucrt64 with this Compiler's installation directory set to "C:\msys64\ucrt64" and Debugger set to "GDB/CDB debugger: gcc-msys2-ucrt64" which is set up with an Executable path of "C:\msys64\ucrt64\bin\gdb.exe" which purports to be "GNU gdb (GDB) 11.2". Having set the Build target to "src", I then commanded CodeBlocks to "Debug/Step into" to begin at the beginning. CodeBlocks responds with:

Active debugger config: GDB/CDB debugger:gcc-msys2-ucrt64
Building to ensure sources are up-to-date
Selecting target:
src
.
.
.
done
Setting breakpoints
Debugger name and version: GNU gdb (GDB) 11.2
Child process PID: 21260
Cannot open file: C:/M/mingw-w64-crt-git/src/mingw-w64/mingw-w64-crt/crt/crt0_c.c
At C:/M/mingw-w64-crt-git/src/mingw-w64/mingw-w64-crt/crt/crt0_c.c:17

Looks like it's referencing MinGW stuff, which of course I'm avoiding. Where does this originate from. So far I've only had to change build scripts, but this may be different! Help!

Navigation

[0] Message Index

[#] Next page