I am trying to debug C++ project in Codeblocks, but it's not stopping at breakpoints. I read the other answers and have tried the following things so far:
(Build Options > Compiler Settings) Produce debugging symbols is checked, strip all symbols is unchecked.
No spaces/non-ascii values in my file path.
Running the debug version.
Debugger in (Settings > Compiler > Toolchain Executables) set to GDB/CDB Debugger:Default
Executable path in (Settings > Debugger > GDB/CDB Debugger:Default) is C:\MinGW\bin\gdb.exe.
Its still not stopping at breakpoints and the debugger log is mentioning that no debugging symbols found
What am I missing here ?
While trying to fix this,I came across a lot of similar questions where CodeBlocks is ignoring breakpoints during debugging, so here's the fixes I have came across so far.
1.Clean and rebuild.
2.Ensure that (Build Options > Compiler Settings) Produce debugging symbols is checked, strip all symbols is unchecked. Please ensure this is done in global settings AND project settings.This fixed it for me.
3.Check so that there are no spaces/non-ASCII values in the project file path.
4.Check if you are running the debug version, not release.The executable from Release build will be \bin\Release , and the executable from a Debug build will be in \bin\Debug .
5. Check that Debugger in (Settings > Compiler > Toolchain Executables) is set to GDB/CDB Debugger:Default.
6.Check that executable path in (Settings > Debugger > GDB/CDB Debugger:Default) is valid gdb path like (C:\MinGW\bin\gdb.exe).
7.Update Codeblocks(last resort).
Please add in comments anything else that worked for you.
I had this problem too, however, it was because a long time ago I'd set
Settings > Debugger > GDB / CDB Debugger > Default > Debugger initialization commands
to
"set follow-fork-mode child"
so GDB was actually debugging another program entirely.
The only thing which worked for me:
Path with spaces
Breakpoints could not work if the path/folder you've placed your project contains spaces or other special characters. To be safe use English letters, digits and '_'.
Source: Debugging with Code::Blocks
Also you can check menu: Build->Select target->Debug
For me the thing which worked was, to delete the file main.o, which is contained in obj/Debug.
Hope it helps someone.
Related
Beginner programmer using Visual Studio release January 2021 on Windows 10. I have yet to get breakpoints to work. When placing a breakpoint in the helloworld.cpp program below and running the debugger, I get the following message and no breakpoint is set.
Breakpoint warning: Unexpected symbol reader error while processing helloworld.exe. - c:\RetireRecipe\Simulator\helloworld.cpp:5
#include <iostream>
using namespace std;
int main()
{
cout << "Hello World" << endl;
}
In my opinion, I suggest that you could try the following methods.
Select Debbug->(APP) Properties, and make suer they are consistent and Debug. Breakpoint operation can only be in Debug mode.
Clean the project, rebuild the project and check if this folder Project Name\Debug has .pdb by Right click your project ->Open Floder in File Explorer.
Go to Debug -> Options and Settings. On the Debugging/General page, clear the Require source files that exactly match the original version option.
Debug -> (app) Properties-> Configuration Properties -> Debugging -> change from Auto to Mixed.
Configuration Properties -> Linker -> Debugging -> Generate Debug Info -> Generate Debug Information optimized for sharing and publishing
If it still work, I suggest that you could reinstall VS.
After several hours of reading various VS Code install videos, I ended up reinstalling twice. The overall solution for me was the reinstall and using the g++ compiler and gdb debugger. I can now set breakpoints, etc.
I'm trying out STM32CubeIDE, and I've been trying to get it to work with the GDB QEMU debugging plugin that's part of the Eclipse CDT package. I've been able to create the project and debug configuration for my STM32F4-Discovery board, and the debugger partially launches, however, just as the simulator starts up, the GUI window it creates suddenly crashes and I get this error:
Error in final launch sequence
Failed to execute MI command:
-target-select remote localhost:1234
Error message from debugger back end:
Truncated register 18 in remote 'g' packet
Failed to execute MI command:
-target-select remote localhost:1234
Error message from debugger back end:
Truncated register 18 in remote 'g' packet
Truncated register 18 in remote 'g' packet
I think this is caused by some mismatch between the CDT plugin I installed and the GCC toolchain that shipped with my installation of Ubuntu 20.04. However, I'm not sure how to fix this.
Is there anything I try to fix this?
So it looks like there were a couple factors as to why this wasn't working. First off, the error messages that I was getting immediately after the GUI debugger terminated were due to an incorrect installation of the arm-none-eabi-gdb package. In order to fix this, I downloaded the package from the ARM site and followed the instructions detailed here. After installing the arm-none-eabi-gdb package again, I went into the project debug configuration settings, navigated to the "debugger" tab in this window, and then changed the GDB executable path from the variables the IDE had set for me to the actual GDB executable path (in this case /usr/bin/arm-none-eabi-gdb).
After that was done, the debugger would no longer immediately terminate, but I was still getting some errors in console shortly after it started (see below). In addition, the debugger GUI would produce no meaningful output, and Ubuntu would warn that the process had frozen.
NVIC: Bad read offset 0xd88
qemu-system-gnuarmeclipse: Attempt to set CP10/11 in SCB->CPACR, but FP is not supported yet.
To solve this, I right clicked the project in the project explorer panel of the IDE, then went to C/C++ build section, then to the Settings section under that, and then finally to the "Tool settings" section of this menu. Under "MCU settings", there are two options for "Floating point unit" and "Floating point ABI", which I changed to "None" and "Software implementation" respectively. After saving these configuration changes, I went to the system_stm32f4xx.c file under the src/ directory of the project, and commented out these lines:
/* FPU settings ------------------------------------------------------------*/
#if (__FPU_PRESENT == 1) && (__FPU_USED == 1)
SCB->CPACR |= ((3UL << 10*2)|(3UL << 11*2)); /* set CP10 and CP11 Full Access */
#endif
After that, I cleaned the project, rebuilt it, and relaunched the debugger. It then functioned normally.
I want to debug my LLVM pass with gdb. I've built llvm with the default make so debugging info should be added.
When I do gdb user/bin/opt it says:
Reading symbols from opt...(no debugging symbols found)...done.
This shouldn't happen because according to the LLVM documentation , 'opt has a lot of debugging info'
http://llvm.org/docs/WritingAnLLVMPass.html#debughints
Is this because I haven't built LLVM correctly ? Any help would be appreciated.
Figured out the complete way to do this : ->
First make sure LLVM is compiled with the debug options which is basically the default setting. If you didn't compile LLVM with non-default options then your current build should be fine.
All LLVM passes are run using LLVM's opt (optimizer) tool. Passes are compiled into shared object files i.e LLVMHello.so file in build/lib and then loaded by the opt tool. To debug or step through the pass we have to halt LLVM before it starts executing the .so file because there is no way to put a break point in a shared object file. Instead , we can put a break in the code BEFORE it invokes the pass.
We're going to put a breakpoint in llvm/lib/IR/Pass.cpp
Here's how to do it :
Step 1 -> Navigate to build/bin and open terminal and type gdb opt . If you compiled llvm with the debug symbols added then gdb will take some time to load debugging symbols , otherwise gdb will say loading debugging symbols ...(no debugging symbols found).
Step 2 -> Now , we need to set a break point at the void Pass::preparePassManager(PMStack &) method in Pass.cpp . This is probably the first(or one of the first) methods involved in loading the pass.
You can do this by by typing break llvm::Pass::preparePassManager in terminal.
Step 3 -> Running the pass . I have a bitcode file called trial.bc and the same LLVMHello.so pass so I run it with
run -load ~/llvm/build/lib/LLVMHello.so -hello < ~/llvmexamples/trial.bc > /dev/null
gdb will now stop at Pass:: preparePassManager and from here on we can use step and next to trace the execution.
I have just installed codelite in my windows 8.1.It shows error
Debugger exited with the following error string:
"No executable
specified,use 'target exec'"
I searched and found this (another stackoverflow question) I did the same as mentioned there but nothing really worked for me.I made a new project and selected Simple executable (g++) and GNU debugger as default debugger.Can anybody help me with this.Also it shows "Program exited with return code: 4199040".
It seems that you don't provide executable to run/debug:
Go to
Project settings... -> Common settings -> General
and fill correct information for
Executable to Run / Debug
Jarod42 provided a 'close enough' answer. On Linux the steps seem to be:
Workspace -> Open Active Project Settings... -> General
and fill correct information for
Executable to Run / Debug
In the command prompt:
gdb (program type: example python or c or c++ etc)
If am running python program then the command will be gdb python
then (gdb) run program_name.py
I am trying to put the gdb to run with eclipse cdt on ubuntu to start debugging some simple programs. So I did the steps I reckon as necessary to get it running:
1. Create an executable project
2. Compile
3. Run
4. Create the file .gdbinit and place it on the main project folder
5. Set some of the debugger configuration:
5. I also tried to find a .gdbinit file that would look some like this:
set schedule-multiple
dir ~/gcc_build/4.7.2/build/gcc
dir ~/gcc_build/4.7.2/gcc
dir ~/gcc_build/4.7.2/gcc/cp
dir ~/gcc_build/4.7.2/gcc/lto
source ~/gcc_build/4.7.2/build/gcc/gdbinit.in
But I didn't find anything similar in my computer, even after doing a:
# find / -name .gdbinit
So, my file .gdbinit end up with the simple content - yes only that:
set new-console on
Then I clicked on Apply and Debug:
The gdb starts working nicely as expected. I press the button "step over / F6" and the debugger goes jumping through the code step by step. Until the point it reaches the command rand() and the gdb hangs with the message:
Can't find a source file at "/build/buildd/eglibc-2.19/stdlib/rand.c"
Locate the file or edit the source lookup path to include its location.
Thus I also tried unsuccessfully to find the rand.c to update this path to include its location:
# find / -name rand.c
# find / -name stdlib
After the error message from GDB complaining that rand.c is missing, then I tried to keep stepping... since then the stepping mode is disable when I restart the debug:
Is this problem happening because some setting for my file .gdbinit is missing? Or some how GDB is not able to find the rand.c from stdlib from c99? When I compile and run the program it runs nicely. Only when I try to launch the debugger is when GDB crashes.
Update: I got the missing rand.c problem after running the commands:
# apt-get install libc6-dbg
# apt-get source libc6
But now a different error appears:
Can't find a source file at "/build/buildd/eglibc-2.19/csu/libc-start.c"
Locate the file or edit the source lookup path to include its location.
Should I also install that library for gdb?
All suggestions are highly appreciated.
From what I saw on your description... looking to the 4th and 5th image you posted, you did right all the required steps.
However, it seems to me that your GDB is attached to several projects. That means that unless you really need that, I would strongly advise you to select all project that you are not currently debugging and delete them from the debugger mode. So, my suggestion is that after you have done all the steps you did so far, then go on:
Debug Configurations > C/C++ Applications: (drop down it)
... then click on each project you are not compiling, with right button from the mouse select "delete" - but don't worry, it will not delete your project, but only the attachment of that project to your debugger mode.
Then restart the eclipse. When you again try to run in the debugger mode, everything will run much smoother than before.
Step1:
Go to https://www.gnu.org/software/libc/ to download glibc.
Step2:
unzip it locally and whenever the eclipse prompts "Can't find ... xxx.c", just load the file into eclipse. It will work.