User forums > Embedded development

Remote debugging

<< < (2/5) > >>

Joerg:
Hi mandrav,


--- Quote from: mandrav on August 01, 2007, 10:09:13 am ---This has been changed recently and those commands are executed after the connection. Mind trying it again now?

--- End quote ---

No, I just tested with SVN4338 from 31. July.
The debugger connects to the remote target, loads the elf file
and breaks at main. So far so good :-)
Hitting the step over button or trying to set a breakpoint gives
no reaction, it all hangs. Like the connection with gdb is lost.
Difficult to say whats going wrong as I can't see any gdb errors.
The remote client (oocd) also says nothing.
I can no unset the breakpoint, all I can do is stop debugging.
Like C::B is waiting endless for gdb reaction.

Hope that helps,
Joerg

mandrav:
Enable the debugger's "debug log" and then start a debugging session. When you stop debugging, paste that log's contents here so we can see what goes wrong (it's the "raw" conversation with gdb).

Joerg:
Sorry, I'm on vacation from today on.  :-)
Hope some other can do more tests on ARM7 remote debugging.
Think its of interest for many more around here.

Joerg:
Hi mandrav,
I'm back again and gave it a try once more.
I want to debug in FLASH this time, using C::B Rev 4446.
What happens is that gdb connects with my remote target (OpenOCD JTAG),
and runs the software.
But it doesn't stop in main() as I told it.
Although C::B shows a yellow arrow on main( ) entry.
All I can do is hit the stop debugger button, which shuts down gdb also.
Didn't found a halt button here.
I need some more advice how to setup things correctly.
Did you already succed in remote debugging with C::B?
This is what the log gives:

Selecting target: debug
Adding source dir: W:\119342_TIDN_Aesculap\Software\ReaderARM7\
Adding source dir: W:\119342_TIDN_Aesculap\Software\ReaderARM7\
Adding file: tidnreadarm.elf
Starting debugger: done
Registered new type: wxString
Registered new type: STL String
Registered new type: STL Vector
Connecting to remote target
Setting breakpoints
Debugger name and version: GNU gdb 6.5.50.20060612-cvs
Connected
At W:/119342_TIDN_Aesculap/Software/ReaderARM7/startup.S:90
At W:/119342_TIDN_Aesculap/Software/ReaderARM7/main.c:103
Debugger finished with status 1

Regards,
Joerg

drZymo:
I am trying to configure Code::Blocks for one of our projects. We use a xscale processor running a linux operating system and the application is compiled on a Windows client with a cross-compiler for that target (with MinGW). The application is to be debugged with a connection to gdbserver running on target. Compilation all goes well and debugging it manually via gdb/gdbserver works perfectly. Unfortunately, the Code::Blocks environment messes up the paths which make setting breakpoints fail.

What I understand so far is that Code::Blocks passes the absolute path of a source file to the compiler. In my case this means that the file D:\CB_TEST\HelloCPP\main.cpp is send to the compiler. This is also put in the debug information.

If in gdb the information about the source files is requested then it will return the following:


--- Code: ---> info sources
Source files for which symbols have been read in:
Source files for which symbols will be read in on demand:
/root/new-build-final/src/gcc-4.2.1/gcc/config/arm/ieee754-df.S, /root/new-build-final/src/gcc-4.2.1/gcc/config/arm/lib1funcs.asm, D:/armeb-linux-uclibc/lib/gcc/armeb-linux-uclibc/4.2.1/../../../../armeb-linux-uclibc/include/c++/4.2.1/iostream, D:/armeb-linux-uclibc/lib/gcc/armeb-linux-uclibc/4.2.1/../../../../armeb-linux-uclibc/include/c++/4.2.1/bits/locale_facets.tcc, D:/armeb-linux-uclibc/lib/gcc/armeb-linux-uclibc/4.2.1/../../../../armeb-linux-uclibc/include/c++/4.2.1/bits/stl_algobase.h, D:\CB_TEST\HelloCPP\main.cpp
--- End code ---

Adding a breakpoint will therefore have to be done with:


--- Code: ---> break D:\CB_TEST\HelloCPP\main.cpp:7
Breakpoint 1 at 0x839c: file D:\CB_TEST\HelloCPP\main.cpp, line 7.
--- End code ---

However, the absolute path that is used by the Code::Blocks debugger uses the "linux notation", which makes the operation fail:


--- Code: ---> break D:/CB_TEST/HelloCPP/main.cpp:7
No source file named D:/CB_TEST/HelloCPP/main.cpp.
--- End code ---

I can't figure out a way to fix this myself, so I would like to advise that the debugger is changed and uses either:

1) the exact same absolute path that is send to the compiler,
2) the absolute paths obtained with 'info sources'.

Or can someone tell me what I did wrong?

Navigation

[0] Message Index

[#] Next page

[*] Previous page