Remote debugging

[mandrav]

(I 'm posting in this forum because that's where remote debugging is needed .

I just committed preliminary support for remote debugging (using gdb). I tested this with gdbserver running on an avr32-linux system and it worked like a charm.
Please test it and provide any feedback you can regarding this.

[killerbot]

Yiannis : makefile.am adjustment for remotedebugging.h

[mandrav]

Yiannis : makefile.am adjustment for remotedebugging.h

Thx, will adjust when berlios starts behaving again. It's not important anyway, it will only break "make dist" (nothing else).

[Joerg]

Hallo mandrav and others,

I just tried the 25.07 nightly build SVN 4321.
I choose TCP connection for my gdb JTAG server (OpenOCD)
and added some commands:

monitor arm7_9 sw_bkpts enable
thbreak main
load
continue

I removed these from the general 'Settings/Compiler and Debugger' tab of course.
This is my Debugger(debug) output:

PATH=.;:\Programme\openocd\bin;D:\Programme\yagarto\tools\bin
Command-line: D:\Programme\yagarto\bin\arm-elf-gdb.exe -nx -fullname  -quiet -args ehzgw.elf
Working dir : D:\Projekte\ehzgw\
> set prompt >>>>>>cb_gdb:
(gdb) >>>>>>cb_gdb:
> show version
GNU gdb 6.5.50.20060612-cvs
.......... snip .............
>>>>>>cb_gdb:
> directory D:/Projekte/ehzgw/
>>>>>>cb_gdb:
> monitor arm7_9 sw_bkpts enable
"monitor" command not supported by this target.
>>>>>>cb_gdb:
> thbreak main
No hardware breakpoint support in the target.
>>>>>>cb_gdb:
> load
You can't do that when your target is `exec'
>>>>>>cb_gdb:
> continue
The program is not being run.
>>>>>>cb_gdb:
> target remote tcp:localhost:3333
0x10002130 in ?? ()
>>>>>>cb_gdb:
> quit

GDB crashes here (or quit).
I don't understand the line
'target remote tcp:localhost:3333'
If this is the command send to gdb than is 'tcp' correct here?

I would expect that my commands to be executed 'after'
the remote connection is established.
But it seems like the commands are send before?
How do you want to split settings between global
and project dependent?
I think the global under 'Settings/Compiler and Debugger' is obsolete
as debugging settings are project specific now?

BTW. I'm missing a stop (break) button for halting execution of target.
As I think the red 'Stop' button shuts down gdb?

Regards,
Joerg

[mandrav]

I would expect that my commands to be executed 'after'
the remote connection is established.
But it seems like the commands are send before?

This has been changed recently and those commands are executed after the connection. Mind trying it again now?

[Joerg]

Hi mandrav,

This has been changed recently and those commands are executed after the connection. Mind trying it again now?

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

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.

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.

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?

[mandrav]

Ah, these things go unnoticed by me because my host and target OSes use the same path separator .
Please report this bug in the tracker so we can fix it.

[Biplab]

Ah, these things go unnoticed by me because my host and target OSes use the same path separator .
Please report this bug in the tracker so we can fix it.

Once you fix this I've to revert one fix. I don't remember exactly the bug report but it is something related to this path problem. I had to use wxFileName to change the path back to Unix style.

[drZymo]

Ok, I have submitted the bug. Can't wait to see this working .

[drZymo]

Any idea when this bug will be picked up?

[thomas]

I had to use wxFileName to change the path back to Unix style.

That is the probably most inefficient way to do this. wxFilename is the devil.