Version: 3.2.2 (using KDE KDE 3.3.1) Installed from: Fedora RPMs OS: Linux I use Kdevelop for embedded debugging. At startup, my gdb produces some additional output,which totally confuses the debugger frontend (while ddd works fine): 1. Debugger stays in busy state, while gdb has already finished downloading and gave already its prompt. 2. Sometimes, when I change the content of the .gdbinit file the situation is wise versa - it thinks that it is in prompt, while gdb is busy and waits for my Ctrl-C which I can not give it at all.
Please provide exact description of what happens. I can't solve this unless you specify what output is produced by your gdb that confuses kdevelop.
Please, find below the dialog with DDD. Note, that .gdbinit file contains one shell command (the echo you can see as Copy...) and "run" command, which must be stopped by the user by ^C. But when the "Press ^C" printout of the .gdbinit appears, Kdevelop is in command state and does not allow to enter ^C in no way. Please, fill free to write me directly (in Russian too) if you need. (gdb) r MPCBDM version 2.0.1 / 2003/5/1 got access rights for printer port 0 addr 0x378..0x37A disabled power at port 0 turned on powering from port 0 adapter version 2 initialized Target cpu PVR=0x00500000 PARTNUM=0x08 MASKNUM=0x01 REV_NUM=0x0004 warning: unknown CPU. Using default register description Ccopy from ../debug/src/tcu(elf32-powerpc) to ../debug/src/tcu.bin(binary) Press ^ ^C Program received signal SIGINT, Interrupt. 0xfff06558 in ?? () Loading section .text, size 0x55fe0 lma 0x10000 Loading section .data, size 0x2000 lma 0x67fe0 Start address 0x10000, load size 360416 Transfer rate: 240277 bits/sec, 511 bytes/write. Breakpoint 1 at 0x102a4: file /Development/Projects/tcu/src/maintask.cpp, line 21. MainTask () at /Development/Projects/tcu/src/maintask.cpp:21 /Development/Projects/tcu/src/maintask.cpp:21:487:beg:0x102a4 Current language: auto; currently c++ (gdb)
Ah, from your second description is sounds that KDevelop simply thinks that when gdb is started, it's in "prompt" mode, and so does not allow you to use Ctrl-C. I think a workaround is to put your initialization command to the "run program" script in KDevelop. OTOH, I'll look at more reliable ways to detect if gdb is in prompt mode, or not.
Exactly vise versa! When I start the debugger in real it is in prompt, but KDevelop thinks it is running! Below is the printout of KDevelop start: (gdb) set edit off (gdb) set confirm off (gdb) (gdb) (gdb) set print static-members on (gdb) tty /dev/pts/11 (gdb) set width 0 (gdb) set height 0 (gdb) set stop-on 1 (gdb) handle SIG32 pass nostop noprint (gdb) handle SIG41 pass nostop noprint (gdb) handle SIG42 pass nostop noprint (gdb) handle SIG43 pass nostop noprint (gdb) set print asm-demangle off (gdb) set output-radix 16 (gdb) cd /Development/Projects/tcu/debug/src (gdb) break /Development/Projects/tcu/src/cc.cpp:24 Breakpoint 1 at 0x167e8: file /Development/Projects/tcu/src/cc.cpp, line 24. (gdb) break /Development/Projects/tcu/src/rms.cpp:63 Breakpoint 2 at 0x10e9c: file /Development/Projects/tcu/src/rms.cpp, line 63. (gdb) break /Development/Projects/tcu/src/sampleio.cpp:180 Breakpoint 3 at 0x1437c: file /Development/Projects/tcu/src/sampleio.cpp, line 180. (gdb) source /Development/Projects/tcu/src/.gdbinit and the .gdbinit script does not run any command but contains only macro definitions.
One more remark. After the above state, I press "stop" and can enter commands. Now I have the opposite situation: I enter the name of macro and ENTER. The macro runs, gdb is in busy state, but KDevelop remains in stop state.
Is this still an issue with the MI interface, Vladimir?
Vladimir, I know you have limited time, but I'd appreciate if you could at least say wether this is potentially still a problem with kdevelop4 or not.
Leo, is this still valid?
Niko, as you provided several patches, I need to apply all of them and test all together. I will do this today, maximum tomorrow morning. Sorry.