Project - compiler changes do not cause debugger to change

[AndrewCot]

On my PC I have Cygwin and MSYS2 (Mingw64), which I have both working with CB. I have created a options_msys2.xml for the MSYS2 migw64 and added it to the default.conf so I do not have to keep changing as the existing MSYS2 is for mingw32. This options and conf setup works in conjunction with multiple GDD configurations for the compilers as well, which is also in the default.conf.

I can use the one project file for both compilers and change the compiler in the Build Options, but when I swap between the two the GDB is not changed. The code does not reload the debugger on a compiler change.

Is this expected?

A work around is to change the compiler in the build options, save the project, close the project and then load it again.

Is the work around good enough or should the code be changed so that when you change compilers the debugger is also changed?

[oBFusCATed]

The compiler can reference a debugger configuration.
And when you use Debug -> Active debugger -> Target's default this would be reflected correctly.
Or you can use this menu to select the debugger config you want to use.

[AndrewCot]

Sorry, looks like I may not have been clear on the question.

If I load a project and then change the build option compiler, should CB change the debugger to the "new" debugger configured in the selected compiler?

If I load a project that is already configured for the CYGWIN compiler/debugger and then change the compiler via the build options to Mingw then the  Debug->Active debugger menu option is set to Target's default , BUT it still runs the Cygwin GDB and not the Mingw GDB that the MingW compiler is configured to use. I have attached the a screen snippet of the debugger options I have setup.


BTW: I have the Cygwin compiler configuration setup to use a Cygwin debugger configuration and the Mingw64 compiler configuration setup to use a Mingw64 debugger. These work correctly so long as I do NOT change between the two compiler configurations via the project's build options after loading the project without performing the work around.

[oBFusCATed]

Works fine for me at least on linux with the CB project.
I have two compilers which have different debugger's configurations selected (settings -> compiler -> [my compiler] -> toolchain executables -> debugger) and if I switch and then use debug -> start it print the correct configuration in the log.

What are the exact steps to reproduce this problem?

[AndrewCot]

CB Setup Background:
1. Configure a MSYS2 debugger configuration to use the C:\msys64\mingw64\bin\gdb.exe executable
2. Configure a Cygwin debugger to use the C:\cygwin64\bin\gdb.exe executable
3. Update the existing Cygwin compiler setup to use the Cygwin configuration from step 2)
4. Copy the existing GCC GNU compiler to "MSYS2 GNN GCC Compiler" and then modify it as follows:
     4a. Change the install directory to C:\msys64\mingw64
     4b. Change the exe filenames to match the "standard" GNU exe. Change the names to use the !windows config options from the options_gcc.xml fie with the exception of the db,windres and make as per the following snippet:
        <Program name="C"         value="gcc"/>
        <Program name="CPP"       value="g++"/>
        <Program name="LD"        value="g++"/>
        <Program name="LIB"       value="ar"/>

The windres and make are not changed, but the db is changed to reference the db from step 1) above

Create working CB Projects:
1. Create a project for a simple hello world program configured for say Cygwin. Call the project as say "CygwinTest.cbp"
2. Start CB and load the project
3. Rename the C:\msys64 to c:\msys64.old
4. Build the project. If it fails then it is configured for msys2. Fix this and try building again
5. Run the debugger. If it fails then it is configured incorrectly or configured for MSYS2. Fix it and try again.
6. Save the project.
7. Rename the C:\msys64.old to c:\msys64
8. Save the project as as say "Msys2Test.cbp"
9. Select Project->Properties menu option.
10. Change the Title to "MSYS2 Test"
11. Select the Ok" button
12. Select Project->Build Options menu option.
13. Select default target on the left pane.
14. Change the selected compiler to MSYS2
15. Say "Yes" to the pop up dialogs
16. Save the project.
17. Rename the C:\cygwin64 to c:\cygwin64.old
18. Build the project. If it fails then it is configured for Cygwin. Fix this and try building again
19. Run the debugger. If it fails then it is configured incorrectly or configured for Cygwin. Fix it and try again.
20. Save the project.
21. Rename the C:\cygwin64.old to c:\cygwin64

Reproduce CB Debugger bug:
1. Close CB
2. Load the "CygwinTest.cbp"
3. Build and run the debuger
4. In the debugger log check that the C:\cygwin64\bin\gdb.exe debugger was used.
5. Select Project->Build Options menu option.
6. Select default target on the left pane.
7. Change the selected compiler to MSYS2
8. Say "Yes" to the pop up dialogs
9. Rebuild the project
10. Run the debuger
11. In the debugger log check that the C:\cygwin64\bin\gdb.exe debugger was still used. This should have changed to C:\msys64\mingw64\bin\gdb.exe, but it did not!!!!

Notes:
1. Be aware that the Cygwin and MSYS2 debuggers can debug both exe's produced.

Current Debugging Status:
So far I have tracked the problem to debuggergdb.cpp following line that loads the wrong GDB.exe. The code above it correctly loads the currently selected compiler, which in the "Reproduce CB Debugger bug:" is the MSYS2 compiler.

Code

cmdexe = GetActiveConfigEx().GetDebuggerExecutable();

[AndrewCot]

Debugging analysis update below on what I have found in addition to the previous posts is below:

The root cause of the issue is that the current CB code does not call eventually call the cbDebuggerPlugin::SetActiveConfig(int index) in cbpplugin as this changes the CB debugger that is to be used when you start the debugger. This causes the debug config to not update, which then causes the cmdexe = GetActiveConfigEx().GetDebuggerExecutable(); line to return the previous exectable file!!!!

I have been able to proof this be hacking the code by adding the following lines to the derbuggergdb.cpp before the cmdexe = GetActiveConfigEx().GetDebuggerExecutable(); line:

    CodeBlocksEvent event2(cbEVT_SETTINGS_CHANGED);
    event2.SetInt(cbSettingsType::Compiler);
    Manager::Get()->ProcessEvent(event2);

THIS IS A HACK AS POC that my conclusion about calling SetActiveConfig(..) is correct.

This code is not correct in that it should be somewhere else in the code and potentially be a different block of code that fits better where the change should be done, but the code should still  end up calling the void DebuggerManager::FindTargetsDebugger() function as this is the function that I have found that should be called when you change the compiler based on my findings as it changes the debugger associated with the new compiler settings.  Be aware that I am not familiar with the Cb code and the correct function to call could be some other function.

[AndrewCot]

I have found in the \src\plugins\compilergcc\compileroptionsdlg.cpp file in the void CompilerOptionsDlg::ProjectTargetCompilerAdjust() function if I add the following block at the end of the function and set the new boolean to true only when the code calls either of the SetCompilerID(...) function calls then I can change the compiler from MSYS2 to Cygwin or vice versa as many times I want in the project build options and the correct debugger executable is then called.

Code

    if (bNotifyUpdate == true)
    {
        CodeBlocksEvent event2(cbEVT_SETTINGS_CHANGED);
        event2.SetInt(cbSettingsType::Compiler);
        Manager::Get()->ProcessEvent(event2);
    }

Is this an acceptable solution? If not point me in the right direction please.

[oBFusCATed]

Nope, this is not acceptable, because cbEVT_SETTINGS_CHANGED is something related to the global settings.
I suppose the problem happens because m_activeDebugger in DebuggerMenuHandler and DebuggerManager are not updated appropriately.

Probably this is the same issue as this one: https://sourceforge.net/p/codeblocks/tickets/611/

[AndrewCot]

Thanks for the feedback. How about the following as a solution:

Code

    if (bNotifyUpdate == true)
    {
        Manager::Get()->GetDebuggerManager()->SetTargetsDefaultAsActiveDebugger();
    }

Ticket 611 is different to this as ticket 611 is if I have read it correctly is that the devs have changed the compiler paths manually, but no the debugger exe and as such the debugger exe is referencing a non existent executable and then when they run the debugger the code  cmdexe = GetActiveConfigEx().GetDebuggerExecutable() loads the non existent directory into the cmdexe variable, but it is not checked to see if it is valid in the cbplug.cpp between lines approx 771 and line 943 where the debugger is launched.

My issue and ticket 611 are different, but related in that the symptom may be interpreted as the same as the debugger does not work, but they are not the same.

[oBFusCATed]

Nope, I'll post a patch later...

[oBFusCATed]

See the attached patch and let me know if it fixes it for you.

[AndrewCot]

Why is there a change in main.cpp as it it to do with scripting?

The patch does fixes the problem.


Any status update on https://sourceforge.net/p/codeblocks/tickets/1086 ?

[oBFusCATed]

Why is there a change in main.cpp as it it to do with scripting?

Because I've found an omission.

The patch does fixes the problem.

Good.

Any status update on https://sourceforge.net/p/codeblocks/tickets/1086 ?

Nope, it is up to Morten to fix it.

[AndrewCot]

Feedback on your commit comments: Please leave ticket 209 and 611 open as these changes will not fix them from what I have found in the code.

BTW There are more important bugs to fix than 611 and 209 IMHO.

[AndrewCot]

I am at ticket 587, but will be finishing up in a few minutes. In the morning I will pull the github changes and build a new version to test with. I am 17 tickets to look at between 587 and 611.

Did you test 611 if you could understand what the dev did? [Or in my case okay, but what the foo bar was the dev thinking when they did this without changing all of the executables...... (Sorry could not resist as I have seen a bunch of these w.t.f. do you think you are doing tickets)].