Code::Blocks GDB Cannot Open file Error - gdb

I use Code::Blocks 12.11 and Cygwin gdb in Windows 8.
I configured the cygwin gdb in code::blocks, when debug, it reports "cannot open file" error. Using gdb in command line is alright.
I found this discussion from web, but I cannot find the registery entry. My guess is that the Debugger plugin cannot pass a right path name to gdb, there is ">>" in prefix of the path, i copied this into editor and it turns out to be two "sub" charaters (1A in ascii).
Here is the error log, the ">>" is added by hand, because when I copied it here, the "sub" charaters don't show.
Debugger name and version: GNU gdb (GDB) 7.6.50.20130728-cvs (cygwin-special)
Child process PID: 21936
Cannot open file: >>/cygdrive/e/code/test/main.cpp
At >>/cygdrive/e/code/test/main.cpp:17
Debugger finished with status 0
My question is
1.How can I make the gdb work in the Code::Blocks
2.Are the two "sub" charaters normal and why do they appear, how can I remove it.

I made it work by doing the following:
I added a String Value under
HKEY_CURRENT_USER\Software\Cygnus Solutions\Cygwin\mounts v2
and
HKEY_LOCAL_MACHINE\Software\Cygnus Solutions\Cygwin\mounts v2
(none of the folders were there, so I had to create them manually by selecting New->Key)
with the following parameters:
name: cygdrive prefix
value: /cygdrive

Related

GDB loading a different file when debuggin raspberry pi PICO?

I'm trying to debug a Raspberry Pi Pico project using openOCD + Picoprobe. I go through the steps that appear to be correct to do all this from my Linux PC (the Get started with Pico and C++ guide is for the Raspberry Pi, but there are tutorials online for PC), but when trying to set breakpoints in gdb, it appears to be looking at a different file.
My steps are the following:
In a console, navigate to the openOCD folder and run:
sudo src/openocd -s tcl/ -f tcl/interface/picoprobe.cfg -f tcl/target/rp2040.cfg
I get only info messages, no errors, until it waits for the gdb to connect
Info : starting gdb server for rp2040.core0 on 3333
Info : Listening on port 3333 for gdb connections
Then, in a different console, I navigate to what I want to debug, in this case the blink.c example. I stand inside the build folder with my .elf file and run
sudo gdb-multiarch blink.elf
(gdb) target extended-remote localhost:3333
(gdb) monitor reset init
(gdb) break 15
where 15 is a relevant debuggable line. But the thing is, the breakpoints are said to be set in a different file:
Breakpoint 1 at 0x20000178: file ../../../../../../libgcc/config/arm/lib1funcs.S, line 1461
and then on, all breakpoints are also set there. Here's an example trying to set 3 different breakpoints:
(gdb) b 15
Breakpoint 1 at 0x20000178: file ../../../../../../libgcc/config/arm/lib1funcs.S, line 1461.
(gdb) b 16
Note: breakpoint 1 also set at pc 0x20000178.
Breakpoint 2 at 0x20000178: file ../../../../../../libgcc/config/arm/lib1funcs.S, line 1461.
(gdb) b 17
Note: breakpoints 1 and 2 also set at pc 0x20000178.
Breakpoint 3 at 0x20000178: file ../../../../../../libgcc/config/arm/lib1funcs.S, line 1461.
So that. I am totally lost on what's happening here. Could anyone point me to why this is happening, or what that file does?
I see it's been a few months but I just ran into the same problem, here's what I've learned.
When you compile the C/C++ program that you're trying to debug, you need to compile it in debug mode, which tells the compiler to include debug symbols in the program. If compiling directly with gcc, you can use the -g flag. However, I'm assuming you're using CMake, in which case you can just add set(CMAKE_BUILD_TYPE Debug) to your CMakeLists.txt (found a few other options here as well)
Probably goes without saying, but after recompiling this way, you'll need to re-load your new program onto your target Pico by holding the bootsel button and plugging it into your machine directly (ie. not via your debugger Pico).
I also found that after doing this, setting breakpoints just to specific lines still didn't behave as expected, and I had to actually specify the name of the file as well, ex: break main.c:15

Issue with launching QEMU simulator from STM32CubeIDE

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.

GDB on eclipse debug mode can't find stdlib/rand.c

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.

Eclipse juno c++ debug error 193

This happened the first time I've tried debugging with Eclipse juno C++:
Error in final launch sequence
Failed to execute MI command:
-exec-run
Error message from debugger back end:
Error creating process <full path>... (error 193)
Running the program using "Run" instead of "Debug" works just fine but when I try debug I get this. I googled about a bit and found somewhere that I should remove any spaces from the directory; I did that but it still isn't working.
The version of eclipse I'm running is:
Eclipse IDE for C/C++ Developers
Version: Juno Service Release 1
Build id: 20120920-0800
Edit:
Problem is sorted! It was because I had forgot the space in my user account name. Because I couldn't be bothered to go through a load of mess changing the folder name in users I just moved my workspace folders straight to my C Drive so the path that it follows is now: C:\eclipse\WorkspaceC++
Thank you very much to john in the comments :)
From OP edit: Problem is sorted!
It was because I had forgot the space in my user account name.
Because I couldn't be bothered to go through a load of mess changing the folder name in users I just moved my workspace folders straight to my C Drive so the path that it follows is now: C:\eclipse\WorkspaceC++

Eclipse CDT 4.2 debug remote external program

I'd like to debug to debug a remote application with GDB.
My target system is a FreeBSD 8.3 box with gdbserver running. The application has been compiled successfully on that box. My Eclipse CDT 4.2 runs on Windows 7 with recent MinGW installed.
This is an external program I'd like to debug. It is neither written by me nor I do have it as a library. I do not intend to write my own program. In this case it is Subversion 1.8.0-dev which I want to debug.
I have created a simple C project, attached the source of Subversion. Created a remote debug config and attached the sources to the running thread in gdbserver.
Now, eclipse enters the main function of Subversion but when I set a breakpoint in another attached source file, Eclipse says: No source file named ra_loader.c or it simply says "No source available".
Then It simply exists the application.
What am I missing here?
Try the suggestion made on this thread
Quote :
1) run a debug session and open the gdb console inside Eclipse
('Console' tab -> 'Display Selected Console' button -> choose the one
ending with 'gdb')
2) use command 'pwd' in the console to print
gdb's current working dir
3) use command 'info line main' to get
the source file where gdb expect to find of my "int main(...)"
function
4) concatenate the result of step 2 with result of step
3 (which should be a relative path) to see if it matches the
correct source file I want
5) use the 'cd' command in gdb (to
change the current working dir) till I get the correct match in
step 4
Knowing the initial working directory (2) and the correct working directory (5) for gdb , I had 2 options: 1) Use gdb's 'cd'
command every time I launch a debug session (I could setup a
.gdbinit file in the gdb initial working directory to do this
automatically) or 2) Setup the 'Source' tab, in 'Debug
Configurations', to make Eclipse use paths that match with gdb's
initial working dir ('Project - Path Relative to Source Folders'
worked for me)