CodeBlocks and Codesourcery GDB

[oBFusCATed]

Does you executable captures Ctrl+C/SIGINT and after that resending it to the real GDB?
If not can you try to implement it and report if this is working?
Keep in mind that you have to have a console allocated in order for this to work.

[Lost_Byte]

Does you executable captures Ctrl+C/SIGINT and after that resending it to the real GDB?

How should it looks?

After SIGINT to debugging exec in C::B "Debugger(debug)" log view contains following (my comments under ///):
/// run exec to while(1) loop...
> continue
/// send CTRL+C
Cannot access memory at address 0x0
Program received signal SIGINT, Interrupt.
0x402b9d58 in ?? ()
>>>>>>cb_gdb:
/// some commands by debugee to obtain current exec state

[oBFusCATed]

I don't understand your question. Can you clarify it a bit?

[Lost_Byte]

Does you executable captures Ctrl+C/SIGINT and after that resending it to the real GDB?

What did you mean under "resending"?
How should it looks for me during debugging session under C::B?

[Lost_Byte]

Does you executable captures Ctrl+C/SIGINT and after that resending it to the real GDB?

Oh.. It seems, I got it... "Executable"- means, my "gdb-cb-bridge" sketch? Is it?
If it's so - answer, no, "gdb-cb-bridge" does not handle SIGINT... I'll try to implement.

[oBFusCATed]

Yes, your executable (gdb-cb-bridge).

Some notes written before your last post:
See this: http://msdn.microsoft.com/en-us/library/windows/desktop/ms686016%28v=vs.85%29.aspx

The idea is that your application should capture the ctrl-c event and then you send the same event to gdb.
When using remote debugging this is the only way to stop gdb/inferior/debuggee.

[ricardo]

OK. Will be brief.
Code Sourcery did not respond. It's not surprising, becouse of Lite is "as is" toolchain, end there is propietary Code Bench.

Hello.  I'm not CodeSourcery support, but the Lite edition tools do have some community mailing lists associated with them.  See http://sourcerytools.com/ for information on how to post to those mailing lists.

[Lost_Byte]

The idea is that your application should capture the ctrl-c event and then you send the same event to gdb.
When using remote debugging this is the only way to stop gdb/inferior/debuggee.

ОК. I've implemented that.
It works in command-line debug session: CTRL+C in gdb-cb-brige becomes a CTRL_C_EVENT for gdb, and it stops the inferior and shows command-prompt.
It does not works under C::B Nightly 11 February 2012 build (7789).

New build of gdb-cb-bridge is in attach.

[Lost_Byte]

The idea is that your application should capture the ctrl-c event and then you send the same event to gdb.
When using remote debugging this is the only way to stop gdb/inferior/debuggee.

Hi, oBFusCATed !
Have you probed new build of gdb-cb-brige? Is there something wrong in implementation?

[oBFusCATed]

I've never tried this bridge, I run linux and also don't use any embedded debugger/compiler.

[Lost_Byte]

Hmmm... For some reason, I thought you were going to work out the feature to stop the debugging process on the fly...

[oBFusCATed]

If cb-gdb-bridge does correctly the ctrl-c re-translation it should work. But I can't guarantee as I've not tried it.
Also getting this console stuff right is pretty tough. I've done many tests in order to make the current implementation work correctly.
I've not tried it since I've implemented it, so I don't know if it still works.

[Lost_Byte]

With what gdb this feature were verified? I would like to try.
The fact that I also use cygwin-GDB for one of my platforms (without bridge), and stopping on the fly from a C::B does not work either.
Checked on Nightly build too.

[oBFusCATed]

Normal gdb used for remote debugging to debug a console application.
I've not tried cygwin.

[Lost_Byte]

Sorry colleagues!
I've found stupid mistake, that leads to overbuffering in some conditions.
That's new build.