Author Topic: Using CodeBlocks to debug itself.  (Read 4597 times)

Offline everSome

  • Multiple posting newcomer
  • *
  • Posts: 34
Using CodeBlocks to debug itself.
« on: January 21, 2022, 12:36:34 am »
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.

Offline AndrewCot

  • Plugin developer
  • Lives here!
  • ****
  • Posts: 678
Re: Using CodeBlocks to debug itself.
« Reply #1 on: January 21, 2022, 01:09:30 am »
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).
« Last Edit: January 21, 2022, 01:14:04 am by AndrewCot »

Offline BlueHazzard

  • Developer
  • Lives here!
  • *****
  • Posts: 3353
Re: Using CodeBlocks to debug itself.
« Reply #2 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

Offline everSome

  • Multiple posting newcomer
  • *
  • Posts: 34
Re: Using CodeBlocks to debug itself.
« Reply #3 on: January 22, 2022, 06:38:12 pm »
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.

Offline everSome

  • Multiple posting newcomer
  • *
  • Posts: 34
Re: Using CodeBlocks to debug itself.
« Reply #4 on: February 01, 2022, 11:45:59 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

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!

Offline AndrewCot

  • Plugin developer
  • Lives here!
  • ****
  • Posts: 678
Re: Using CodeBlocks to debug itself.
« Reply #5 on: February 02, 2022, 03:53:49 am »
I would suggest you go back and start again and do the following to ensure your setup is correct as I cannot help with your existing setup as it has not been tested yet to my knowledge:

1) Remove all existing C::B installations.
2) Install the latest nightly into say C:\Program Files (x86)\codeblocks as per the nightly instructions.
3) Check that MSYS64 MINGW64 is installed in C:\msys64\mingw64. If not then remove ore rename your existing MSYS2 directory to say <existing name>.backup and install the MSYS2 Mingw64 packages. I think the following are the main ones, but in my script I install a bunch more:   

   pacman -S mingw-w64-x86_64-toolchain msys2-runtime-devel zip unzip mingw-w64-clang-x86_64-toolchain     
   
   pacman -Syu
4) Check that you can create a simple printf hello world and that it runs5) Grab the CB SF SVN source with NO mods6) Follow the instructions in the attached file.
Once you have C::B working with MSYS2 Mingw64 build then you can try the ucrt64 as you have a working starting point, which you do  not have at the moment.
« Last Edit: February 20, 2022, 12:33:41 am by AndrewCot »

Offline everSome

  • Multiple posting newcomer
  • *
  • Posts: 34
Re: Using CodeBlocks to debug itself.
« Reply #6 on: February 09, 2022, 01:42:30 am »
Out of curiosity, how is the current interface to gdb implemented? From 4 November 2012, the wiki page "Debugger plugin" states "The next generation of debugger plugin will use the GDB-MI interface, and it is under developement, but it is at least usable." While the GDB wiki in their "GDB front ends and other tools" page
https://sourceware.org/gdb/wiki/GDB%20Front%20Ends
lists Code::Blocks under the section:
1.3. Using the old (deprecated) annotations mechanism (please fix them!)

Offline AndrewCot

  • Plugin developer
  • Lives here!
  • ****
  • Posts: 678
Re: Using CodeBlocks to debug itself.
« Reply #7 on: February 09, 2022, 02:31:43 am »
The current GDB debugger plugin uses the annotations mechanism and unfortunately it does not build against the latest SVN C::B code due to changes in C::B since it was last worked on.

Search the forum for "GDBMI" and read up if you want to help out with it. To save yourself time in case you do not come across the GDBMI plugin redo in the forum it is: https://github.com/obfuscated/cb_gdbmi .
If you do want to work on it then I would suggest if you get stuck on something then have a look at CodeLite source as it has a working GDBMI debugger and you can see how it works and borrow the concepts if needed to get past what you are stuck on.

Offline ollydbg

  • Developer
  • Lives here!
  • *****
  • Posts: 5906
  • OpenCV and Robotics
    • Chinese OpenCV forum moderator
Re: Using CodeBlocks to debug itself.
« Reply #8 on: September 16, 2022, 08:39:20 am »
Hi, everSome, some one put the similar method (calling sh/bash, and run script in the sh/bash) in the wx forum.

See here: MSYS2 wx-config from command prompt (CMD) workaround / fix
If some piece of memory should be reused, turn them to variables (or const variables).
If some piece of operations should be reused, turn them to functions.
If they happened together, then turn them to classes.