Let me clarify: your .gdbinit has "continue" and so when gdb is loaded it's immediately in "running" state. You want to send Ctrl-C to gdb, but cannot, because kdevelop only shows "pause execution" button when he things the application is running, while it things it's stopped. Right?

First question: why do you need this "continue" + "Ctrl-C" combination?

Small correction - after loading gdb I run macro, which does what ou described.
To your question - the unit has the "boot loader" which initializes RAM and sets some memory values. Macro starts with making HW reset to the target. Then I need to let the CPU to run a bit to execute boot loader and set RAM and values. Next, I do Ctrl-C and now can send gdb commands to download the code via BDM (the special interface for debugging) and finally "continue" to run the downloaded application.

So, Ctrl-C is to give the boot loader some time, right? Why don't you just use
"shell sleep XXX" in your gdb macro, followed by the gdb command to download the code, followed by "continue"?

Because of 2 reasons:
1. To download via BDM I neet to stop the CPU. Only in the stop it can accept commands.
2. "shell" command is executed in parallel with gdb - it does not wait for it to finish.

But IMHO, we "lost here the baby". 
I spoke about the front end been not synchronized with the gdb. And, BTW, I have now the more simple case - I start the debugger and it is already in busy state, while actually gdb is in prompt. I think - this is the case. 
Now, when severe lost of sync occurs, I need to reopen the kdevelop, because the front end is not operational any more at all. And I observed several times the situation when this lost of sync caused the X-Windows to crash when I reopen the kdevelop.

So, as a final clarification:
1. You run your macro that contains "continue"
2. KDevelop thinks the application is not running, so does not allow you to send "Ctrl-C". Right?

Sorry for the late answer - I was out of the office...
Generally - yes.
In details:
1. Consider the .gdbinit script, which contains the 'load' command. This command execution via BDM, serial line or similar takes significant time -10-20s. During this time, gdb is busy, kdevelop thinks it is not.
2. If script contains "contine", KDevelop does not see that gdb is busy.

Hope this helps. If no, let me know - i shall try to elaborate some better example.

Vladimir, here is the worst case example.
I have the following text in the .gdbinit file:        set mpcbdm_adapter 2
        target mpcbdm 0
        set mpcbdm_dflush off
        set $pc=0xfff00100
        shell ./tftp_load &
        continue
If the tftp server does not answer, the tftp_load script waits printing dots (I think this is irrelevant, but still...)

Now, when I run this, I see dots and there is no way to cancel this, as KDevelop is in stopped state.

BUT!!!!
When I stop the debugger (by pressing red "X" button), this causes the X-windows to crash!
I checked this several times - the result is stable, X crashes and restarts. No error messages are produced.

Best Regards

It looks like there's no 100% nice fix, because in general, it's not possible to ask gdb if it's running a command or just busy itself, like reading huge symbol tables.

I think I'll either make the "Interrupt" button always enabled (like is done in DDD), or make it enabled after certain timeout.

I vote for "always enabled" with both hands. There is no harm at all if one presses "Interrupt" (sends Ctrl-C), while gdb is not busy.

And, please, can you estimate when this will be available? (It is very uncomfortable to switch to compile in KDevelop and debug in DDD).

Thanks ahead a lot.

Speaking about "Interrupt" button in gdb window -- I'll commit this change in half an hour. I'll also need to find where the "Interrupt" menu item got disabled.

There are other followup changes -- like preventing entering new gdb commands when the previous one has not finished, but that's not part of this bug report.

BTW, I don't know how this is done in DDD, but it never is confused by an incorrect gdb state - it does not display the prompt till gdb is ready to receive a command. Again, I don't know, but I noticed that when gdb is busy sending any command does nothing - it does not reply, which may be an indication...
Sorry...

Yes, I noticed that fact that DDD will accept the comamnds even if gdb is busy, and that's something I don't like and will eventually fix.

SVN commit 501919 by vprus:

Don't disable the "Interrupt" menu item and the "Interrupt" button
in gdb window when gdb is in "paused" state. The problem is that gdb
does not allow to correctly test if application is running or not, especially
when application was started by user-defined command containing "continue" 
inside. In such cases it's not possible to stop the application at all.

The problem with this patch is that after interrupting the application,
the current source line is not shown. That will be fixed later,
when I port everything to MI.

CCBUG: 111828


 M  +1 -1      gdbcontroller.cpp  
 M  +4 -2      gdboutputwidget.cpp  
 M  +0 -1      kdevdebugger.rc  


--- branches/kdevelop/3.4/languages/cpp/debugger/gdbcontroller.cpp #501918:501919
@@ -382,7 +382,7 @@
             delete cmdList_.take(i);
     }
 
-    if (dbgProcess_ && stateIsOn(s_appBusy))
+    if (dbgProcess_)
         dbgProcess_->kill(SIGINT);
 }
 
--- branches/kdevelop/3.4/languages/cpp/debugger/gdboutputwidget.cpp #501918:501919
@@ -137,15 +137,17 @@
         m_userGDBCmdEditor->setEnabled(false);
         return;
     }
+    else
+    {
+        m_Interrupt->setEnabled(true);
+    }
 
     if (statusFlag & s_appBusy)
     {
-        m_Interrupt->setEnabled(true);
         m_userGDBCmdEditor->setEnabled(false);
     }
     else
     {
-        m_Interrupt->setEnabled(false);
         m_userGDBCmdEditor->setEnabled(true);
     }
 }
--- branches/kdevelop/3.4/languages/cpp/debugger/kdevdebugger.rc #501918:501919
@@ -67,7 +67,6 @@
     <Action name="debug_memview"/>
   </enable>
   <disable>
-    <Action name="debug_pause"/>
     <Action name="debug_core"/>
     <Action name="debug_attach"/>
   </disable>

Valdimir can this bug be closed as fixed?

assuming fixed as there's a lot better support since this was done.