Code::Blocks Forums
Developer forums (C::B DEVELOPMENT STRICTLY!) => Development => Topic started by: lesnewell on July 10, 2010, 08:25:29 pm
-
Some version of GDB have problems with path names that include spaces. Specifically I am using GDB 7.1 targeted for a remote ARM target, running Code::Blocks on Windows.
When you run GDB, Code::Blocks specifies the source root directory as a short file name which GDB understands. However when you set a breakpoint, C::B specifies the source file name as a full path, including spaces. The attached patch uses short file names. I have only tested it on this setup, not on Linux or trying to debug a Win32 app. It should be OK but it would be good if a few people could test it to see if it breaks anything.
Something that would be really useful to me would be an option to run an external command when you press the 'stop debugger' button. To stop the remote target I either need to send 'monitor halt' to GDB or Telnet to OpenOCD (the bridge between GDB and the target) and send the command 'halt'.
By the way, is there any way of running a command in a detached console when you run the debugger? Currently I have OpenOCD as a separate tool that I have to remember to run before I run GDB. This is only a minor inconvenience as OpenOCD keeps running when GDB exits.
[attachment deleted by admin]
-
When you run GDB, Code::Blocks specifies the source root directory as a short file name which GDB understands. However when you set a breakpoint, C::B specifies the source file name as a full path, including spaces. The attached patch uses short file names. I have only tested it on this setup, not on Linux or trying to debug a Win32 app. It should be OK but it would be good if a few people could test it to see if it breaks anything.
Probably this should be made configurable and as it seems it won't break the debugger on linux.
Something that would be really useful to me would be an option to run an external command when you press the 'stop debugger' button. To stop the remote target I either need to send 'monitor halt' to GDB or Telnet to OpenOCD (the bridge between GDB and the target) and send the command 'halt'.
Do you run in remote debugging mode?
Do you think we could send the commands automatically in remote debugging mode or this is specific to your target/device?
Also there was a discussion recently about terminating the debuggee in remote debugging mode, currently C::B does it wrong.
The correct way is to send Ctrl+C and its equivalent on windows, but we currently send SIGINT and call API function on windows.
Do you think you could help us to implement this feature?
Also could you try the debugger branch, where all the development in regard to the debugger is happening at the moment?
By the way, is there any way of running a command in a detached console when you run the debugger? Currently I have OpenOCD as a separate tool that I have to remember to run before I run GDB. This is only a minor inconvenience as OpenOCD keeps running when GDB exits.
Can you explain better what exactly do you want?
p.s. sorry if my post is too chaotic...
-
Probably this should be made configurable and as it seems it won't break the debugger on linux.
As it is, it won't affect Linux at all. On Windows it should work with all versions of GDB but I haven't tested it.Do you run in remote debugging mode?
Do you think we could send the commands automatically in remote debugging mode or this is specific to your target/device?
Yes this is in remote mode. Debugging remote ARM targets is a little convoluted. OpenOCD is a daemon running on the PC that accepts TCP and Telnet connections then routes the commands to the target over JTAG. JTAG is a standard debugging/programming hardware interface used by a number of semiconductor manufacturers. The whole signal path is:
GDB->TCP connection to OpenOCD->USB JTAG adapter->target
As the target is not running an operating system as such, you can't send a SIGINT, Ctrl+C anything similar to it. With my particular setup you send a command 'halt' to OpenOCD which then physically stops the target processor via JTAG. The 'monitor' command in GDB send commands to the remote monitor (in my case OpenOCD). The full command in GDB would be 'monitor halt'. I am sure other remote targets will work differently The correct way is to send Ctrl+C and its equivalent on windows, but we currently send SIGINT and call API function on windows.
Remote targets need to be handled differently to local targets. Maybe add an extra box in 'Remote connection' to specify what command needs to be sent to GDB. Actually I am not sure if GDB will respond to commands while the target is running. If not you can use Telnet to send a command directly to OpenOCD. I'll have to do some tests.Do you think you could help us to implement this feature?
Also could you try the debugger branch, where all the development in regard to the debugger is happening at the moment?
I would like to help. I found your debugger branch yesterday. I downloaded it but haven't yet tried building it. I'll let you know how I get on.
By the way, is there any way of running a command in a detached console when you run the debugger? Currently I have OpenOCD as a separate tool that I have to remember to run before I run GDB. This is only a minor inconvenience as OpenOCD keeps running when GDB exits.
Can you explain better what exactly do you want?
Basically I just need a option in 'Additional shell commands' to allow the commands to be run in a detached console. I.e. they would run in their own independent console that runs asynchronously. Maybe the easiest way would be to simply grab the same options and code that are used in user defined tools. In fact another way round it would be to have an option to run a user defined tool before you run GDB.
-
"'Additional shell commands' to" is not yet implemented *I think*, it is already in the gui, but doesn't execute the commands yet.
-
Is 'Additional GDB commands' implemented? I can work around 'additional shell commands' but 'additional GDB commands' is essential for me.
-
that one is , yes.