Author Topic: why is gdb not even started!  (Read 5350 times)

Offline starkeeper

  • Multiple posting newcomer
  • *
  • Posts: 15
why is gdb not even started!
« on: October 27, 2007, 01:32:19 pm »
Hi,
I'm pleased to see that here has been created a discussion corner for embedded guys. I'm using CB for some month now. Now with the newest version I was able to integrate my asm-files and my linker script so I don't had to use my own makefile anymore. Good work guys!

But there is a major problem now with GDB. I can't get it running.
Under Settings->Compiler and Debugger->Toolchain Exec.->Debugger is "arm-elf-gdb.exe" selected and that is correct. I also have enable the option display debugger log under the settings to see the debugger output.
I compile my project and select Debug->Start. Now I expect that gdb is startet and gives me some errors, but nothing happens.
The only change is that in the Tab "Code::Clocks Debug" the line "DebuggerGDB::OnCompilerFinished" is added. Both tabs "Debugger" and "Debuger (debug)" stay untouched..

Also adding an init command like: "target localhost:3333" is not helping.

So what did i not understand?

Offline starkeeper

  • Multiple posting newcomer
  • *
  • Posts: 15
Re: why is gdb not even started!
« Reply #1 on: October 28, 2007, 09:16:41 am »
Well this Thread seems to interest many visitors here, but none of you had an idea.. So I had to figure it out by my own. My Programm is compiled with -Wall so I get some warnings while compiling. But regardless the warnings I had a running elf-file and this could be used for debugging - nomally. But it seems that the C::B debugger only starts after compilation, if there are of course no errors and warnings! I was able to debug my code after compilation with option -w what gives me no warning.

Can someone confirm that? Is it meaningful to suppress debuging of code that throws warnings?

However I can not debug, because C::B is using other directories than my compiler. The compiler uses relative paths to set symbolnames and so on.. But C::B uses the full path to set a breakpoint. The result is this message from GDB:
Code: [Select]
break "C:/Dokumente und Einstellungen/Administrator/Eigene Dateien/Elektronik/ARMProjects/ARM Roboter/src/main.c:140"
No source file named C:/Dokumente und Einstellungen/Administrator/Eigene Dateien/Elektronik/ARMProjects/ARM Roboter/src/main.c.
Breakpoint 1 ("C:/Dokumente und Einstellungen/Administrator/Eigene Dateien/Elektronik/ARMProjects/ARM Roboter/src/main.c:140) pending.

GDB expects somethng like "src/main.c". Maybe this could also be a problem caused by the spaces in the directory names, I will have to check this.
« Last Edit: October 28, 2007, 09:22:24 am by starkeeper »

Offline drZymo

  • Single posting newcomer
  • *
  • Posts: 9
Re: why is gdb not even started!
« Reply #2 on: October 29, 2007, 08:43:46 am »
Then this is probably related to the bug I mentioned in http://forums.codeblocks.org/index.php/topic,6514.msg54364.html#msg54364

Offline starkeeper

  • Multiple posting newcomer
  • *
  • Posts: 15
Re: why is gdb not even started!
« Reply #3 on: October 29, 2007, 06:16:26 pm »
Yes maybe it is the same problem, but I'm using the same system for debugger and target. I see that CodeBlocks uses the slash as the seperator and my windows system normally uses the backslash.

However executing the command "break main" gives me: "Breakpoint 1 at 0x620000e0: file src/main.c, line 144.". You can see that GDB itself uses the slash, that is also used be CodeBlcoks.