News:

When registered with our forums, feel free to send a "here I am" post here to differ human beings from SPAM bots.

Main Menu

Source File Not Found in arm-none-eabi-gdb

Started by tipofthesowrd, December 24, 2014, 02:09:21 PM

Previous topic - Next topic

tipofthesowrd

I've seen several topics on this issue but most of them were quite old and for the life of me all the solutions I've tried from these topics have not fixed this problem.

I'm currently using Code::Blocks as my main development method for embedded software. (The dreaded Em::Blocks works very nicely but the old layout, no linux and the fuzzy license make me wanna stick with the original ;D)

To debug I use my trusty openOCD and the current Windows version of the latest 4.9 GNU compiler and gdb for ARM Embedded.

Manually setting breakpoints via the Code::Blocks debugger command line such as 'break main' or 'main.cpp:150' work fine and get triggered correctly to prove my binary included debug symbols.

When setting a breakpoint via the GUI I get the dreaded 'Source file not found' error. In the past there seems to have been an option to compile with full path (GDB Workaround) but I can't find this option anymore.

Besides that, since the the debug symbols seem to be compiled relativly isn't there an option to tell Code::Blocks to reference the source files also relatively towards gdb?

oBFusCATed

The option for using full paths should not be removed. It should be somewhere in the Settings->Compiler -> ... -> Advanced.
(I have no C::B in front of me to tell you where to find it, exactlty).

Can you try to reproduce the same problem with the desktop versions of the compiler and the debugger, so I can have a way to reproduce this problem? Probably trying to use the remote debugger could help...
(most of the time I ignore long posts)
[strangers don't send me private messages, I'll ignore them; post a topic in the forum, but first read the rules!]

tipofthesowrd

#2
First, I found the "GDB workaround" option. Which fixes the issue.
So for future reference the location of the options is: Settings -> Compiler --> Tab 'Other Settings' --> 'Advanced options'

The basic consoleApp with MinGW and GDB works fine out of the box.
After trying with a basic consoleApp I checked the commands sent to GDB:

Standard GDB with MinGW
Quotebreak "C:/windowspathwithspaces/main.cpp:39"
[debug]Breakpoint 3 at 0x4014d5: file C:\windowspathwithspaces\main.cpp, line 39.
[debug]>>>>>>cb_gdb:

ARM Embedded GDB
[debug]> break "C:/windowspathwithspaces/main.cpp:62"
[debug]No source file named C:/windowspathwithspaces/main.cpp.
[debug]Breakpoint 6 ("c:/windowspathwithspaces/main.cpp:62") pending.
[debug]>>>>>>cb_gdb:


So from C::B point of view everything seems to be the same.
So the full paths option is standard on GNU GCC which is installed with C::B but not for GNU GCC for ARM? (Since these are the settings I used as a baseline for my GNU GCC for ARM Embedded compiler target)

Explains the confusion

danselmi

For reference, I had the same problem with arm-none-eabi-gdb.
The solution was to specify the full path to the elf file in the "Additional GDB commands" in "project  options -> Debugger":

monitor reset halt
file c:/data/xy/bin/Debug/xy.elf
load
spell checker plugin: [url="http://developer.berlios.de/projects/spellchecker/"]http://developer.berlios.de/projects/spellchecker/[/url]
nassi shneiderman plugin: [url="http://developer.berlios.de/projects/nassiplugin"]http://developer.berlios.de/projects/nassiplugin[/url]

Quiss

Instead of specifying full path, below line works in the "Additional GDB commands" even there are spaces in the full path:
file ./Debug/bin/$(TARGET_OUTPUT_BASENAME).elf

tipofthesowrd

Quote from: Quiss on December 31, 2014, 08:20:01 AM
Instead of specifying full path, below line works in the "Additional GDB commands" even there are spaces in the full path:
file ./Debug/bin/$(TARGET_OUTPUT_BASENAME).elf

Unfortunately, no. I just tried with the following debugger commands:


monitor halt
file ./Debug/bin/$(TARGET_OUTPUT_BASENAME).elf
load ./Debug/bin/$(TARGET_OUTPUT_BASENAME).elf
monitor sleep 100
continue


They still result in the "No such file or directory" error. Perhaps this has to do with my Windows machine?
Perhaps the GDB workaround option should be made more clear or easier to find?