Details: The exception is: MI type error The MI response is: ^done,threads=[{id="1",target-id="Thread <main>",frame={level="0",addr="0x00000000",func="_vectors",args=[]},state="stopped"}],current-thread-id="1" This happens when using a ARM cross-compiler toolchain: GCC: arm-none-eabi-gcc (GCC) 4.9.3 20150318 (prerelease) Copyright (C) 2014 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. GDB: GNU gdb (GDB) 7.9 Copyright (C) 2015 Free Software Foundation, Inc. License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html> This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. Type "show copying" and "show warranty" for details. This GDB was configured as "--host=x86_64-unknown-linux-gnu --target=arm-none-eabi". Type "show configuration" for configuration details. For bug reporting instructions, please see: <http://www.gnu.org/software/gdb/bugs/>. Find the GDB manual and other documentation resources online at: <http://www.gnu.org/software/gdb/documentation/>. For help, type "help". Type "apropos word" to search for commands related to "word". GDB Server: SEGGER J-Link GDB Server V4.96l Command Line Version JLinkARM.dll V4.96l (DLL compiled Feb 25 2015 10:11:08) WARNING: Unknown command line parameter --version found. -----GDB Server start settings----- GDBInit file: none GDB Server Listening port: 2331 SWO raw output listening port: 2332 Terminal I/O port: 2333 Accept remote connection: yes Generate logfile: off Verify download: off Init regs on start: on Silent mode: off Single run mode: off Target connection timeout: 0 ms ------J-Link related settings------ J-Link Host interface: USB J-Link script: none J-Link settings file: none ------Target related settings------ Target device: unspecified Target interface: JTAG Target interface speed: 1000kHz Target endian: little Reproducible: Always Steps to Reproduce: 1. Configure Debug Launcher debugger executable=/usr/src/development/gcc-4.9/install/bin/arm-none-eabi-gdb run gdb script: /path/to/debug_ram debug_ram: # Cortex M3 debugging target remote localhost:2331 monitor speed 1000 # load ELF symbols into debugger file helloworld.elf # load ELF to target load helloworld.elf monitor SWO EnableTarget 209715200 1000000 1 0 monitor reset # run to main set breakpoint pending on #break main #continue 2. Select new debug launcher 3. Start debugging Actual Results: message box "The debugger component encountered internal error while processing reply from gdb. Please submit a bug report." Afterwards debuggin works more or less: Stepping, Continue and inspecting variables work. Setting breakpoints from GUI does not work! Setting breakpoints using GDB cmd prompt works. Expected Results: The debugger should work without issues ;-) I was already using different toolchains for different targets: ARM, PPC, MSP430. I never got KDevelop' debugger working with these toolchains. So these seems to be a more generic problem. The same toolchains work with cgdb and ddd frontends.
Maybe the problem is clear from the description. If not and you need a toolchain to reproduce the problem I can provide the script I used to build the toolchain. And it is also possible to reproduce the problem with QEmu without real hardware. So let me know if you need help to reproduce the issue.
Hi Gerhard, thank you for the report. I'm interested in support of more "exotic" debug configurations, and have already done work in that direction, but that work has all happened in Git master. The error you get looks like a typical case of KDevelop not staying properly in sync with GDB's MI protocol. I have fixed many problems like that, but it's unclear whether those fixes will ever be backported. I would very much appreciate if you could try KDevelop master (based on KF5...) to see if the bug still occurs there.
Created attachment 92297 [details] signature.asc Hi Nicolai, do I need both kdeveplatform and kdevelop from master, or only kdevelop? On 04/28/2015 11:23 AM, Nicolai Hähnle wrote: > https://bugs.kde.org/show_bug.cgi?id=346827 > > Nicolai Hähnle <nhaehnle@gmail.com> changed: > > What |Removed |Added > ---------------------------------------------------------------------------- > CC| |nhaehnle@gmail.com > Resolution|--- |WAITINGFORINFO > Status|UNCONFIRMED |NEEDSINFO > > --- Comment #2 from Nicolai Hähnle <nhaehnle@gmail.com> --- > Hi Gerhard, thank you for the report. I'm interested in support of more > "exotic" debug configurations, and have already done work in that direction, > but that work has all happened in Git master. > > The error you get looks like a typical case of KDevelop not staying properly in > sync with GDB's MI protocol. I have fixed many problems like that, but it's > unclear whether those fixes will ever be backported. > > I would very much appreciate if you could try KDevelop master (based on KF5...) > to see if the bug still occurs there. >
Yes, you need both, since the debugger component crosses both projects. I want to be fair and explicitly warn you: Depending on your distribution, you may need even more than that, because kdevplatform/kdevelop master are based on KF5, which some distributions are adopting rather slowly. On Ubuntu 14.10, the list of packages that I installed myself at some point includes: extra-cmake-modules, grantlee, kde-dev-scripts, libkomparediff2, kdevplatform, kdevelop. Obviously it depends on your distribution whether you need all of them. Still, if you could manage to test that, I would be very happy and promise to do my best to fix all debugger issues you run into :)
Created attachment 92351 [details] kdev-4.7.1-gdb.patch
It seems that this is caused by this commit: http://quickgit.kde.org/?p=kdevelop.git&a=blobdiff&h=ae6b5b864b6e133c6c15b0d8a7ab1e1df6baba47&hp=68e1768e286e06bf69be37bed906e11cb4c144f6&hb=7f5008b07506e6a4b0d817bf7735be4d19da8790&f=debuggers%2Fgdb%2Fgdb.cpp It assumes that thread-group-started will come as a response to -exec-run (judging by the comment) and it marks the last command as received getting out of sync with gdb. I have a similar setup and it is received when the gdbinit script is loaded. I uploaded a patch, I just set the replyReceived flag only if the current command is exec-run. I'm not sure if that's the right fix but it works for me. See gentoo bug here: https://bugs.gentoo.org/show_bug.cgi?id=544410
Reopening as per investigation/patch in comment #6.
Created attachment 93628 [details] Remote debugging example setup with gdbserver on localhost This is a very basic project that shows the defect, with script to run gdbserver on localhost and another script to connect gdb to it when you hit debug. as discussed here: http://comments.gmane.org/gmane.comp.kde.users.kdevelop/8263
Forgot to mention... the supplied test example requires kdevelop, gdb, gdbserver to be installed, shows the fault with kdevelop 4.7.1 and not with kdevelop 4.7.0. Tested on fedora 20 x64 but the example should compile and run on anything, no special hardware required. GDB scripts rely on absolute paths, so I have set this example up to be extracted in /tmp
Thank you, Funcster! If I were you, I should set the importance of the bug as critical, is it makes usage of the buggy version impossible - all we 'remote debuggers' downgraded to something working...:-)
I will look into this the coming days while at akademy. Can you tell me how to set things up? Extract to /tmp, then what? 1) import project in kdevelop 2) any configuration? 3) run_gdbserver.sh 4) ??
The project has a launcher set up that runs all the scripts for you, so... 1) import project (the .kdev4 files etc. should be present in the zip) 2) start debugging (what's the default key, F9?) You should get the MI Type Error popup straight away. Thanks!
I just tried it with the KF5 version of KDevelop and don't get any error. I can start debugging, and stop at a breakpoint in main etc. pp. - it all seems to work just fine. Could you guys try again with the latest and greatest of KDevelop? Maybe this issue is fixed already? Leon, you said you had serious issues with GDB in KF5, could you try to adapt this example with KF5 to reproduce your problems? Note that I intend to release a first beta of KF5 based KDevelop next week, thus spending time on fixing this in KDE4 is not really high on my priority list.
Milian, sorry - what version numbers are KF5? I updated to kdevelop 4.7.2 or 1, not remember exactly. Is it KF5 already?
Ah, no - that is still KDELibs 4 based. In git master of KDevelop we depend on frameworks 5, and the version for KDevelop there currently is 4.9.90 and will become 5.0.0. If you have the time, it would be cool if you guys could try to compile KDevelop against KF5, for me it looks like it's fixed there. Maybe you could also wait until beta packages for the 5.0.0 release hit your distro of choice, or some other distro which you can install in a VM, if you cannot compile it yourself.
Hi Milian, Is the change proposed by Fernando above included in the latest and greatest? If so that would tie up with you not getting the error. Setting up everything required for compiling the latest is just too much disruption for my main OSes, maybe when the betas are out I could try setting up a VM. However, I would've thought that getting the fix into a 4.7.2 release would make sense as it will provide a working environment for those who don't always live on the bleeding edge. I'll need to move to fedora 21 at some point soon but can't until there's a working KDevelop in the repos!
Voting with both hands here on this side of the Earth...:-)
Hiu Funkster, compiling KF5 is too much trouble, also on my Gentoo. I used the special Ubuntu iso from here https://techbase.kde.org/Projects/KDevelop4/HowToCompile and installed it in a KVM. This works quick and easy. Cheers, Gerhard.
The code in question has been completely rewritten on git master. The problem only affects version 4.7.1. That's the latest release and what most distros are using so it should be fixed.
Hello, Fernando. Do I understand correctly, that I need to download the 4.7.1 version, apply the patch you provided and then it will work? or I misunderstood something?
@Fernando: I completely missed your patch, sorry for that. Please put patches in future up to reviewboard.kde.org - thanks! @Leon: Yes, please apply his patch and test it, if it works I'll apply it to the 4.7 branch. Cheers
@Milian: no problem, will do so next time. @Leon: That's correct.
I applied the patch. The situation is much better, but still are some problems: - No MI interface errors are issued any more. -. Preinserted breakpoints work as expected. But insertion of a new breakpoint into the running application is ignored. Also pressing the interrupt button does nothing - application continues to run. Hope this helps...
OK, so that means at least that Fernando's patch fixes some issues - I'll push it now then. Regarding the other bugs please open new bug reports and again add explicit instructions on how to reproduce them.
Git commit 633b49c4bd7e434185c69a3dea1841755b75dcba by Milian Wolff, on behalf of Fernando Rodriguez. Committed on 02/08/2015 at 14:20. Pushed by mwolff into branch '4.7'. Set the replyReceived flag only if the current command is exec-run. Fixes various MI errors in remote debugging scenarios. M +2 -1 debuggers/gdb/gdb.cpp http://commits.kde.org/kdevelop/633b49c4bd7e434185c69a3dea1841755b75dcba
I am not sure this right thing to close this issue. This bug report has already several descriptions and attachments. I do not have them. And I hope Fernando simply needs to take into account this (I suppose this is one) specific case only. Sorry, if I am not right...
Leon: What was the last version where everything worked for you? I've noticed those too but I think they started before the issue that the patch fixes and I have workarounds for them so they didn't bother me enough to look into it, but I will when I get time. I usually debug a QEMU vm so I just pause QEMU and the debugger breaks, then I can set breakpoints. For debugging an x86 kernel with a gdb stub I issue an int 3 instruction from my code and the debugger breaks (this probably works when debugging through gdbserver as well). For the rare cases when that's not enough I've been using kdbg or gdb directly.
My previous version was 4.5.2 - worked fine. I hope I understand what you described - but you concentrated in one last problem - not stopping on interrupt button. The second issue is more important - insertion of a breakpoint while the application is running. Actually this means that you need to set BP before running the application - otherwise it will not be set and, as the interrupt does not work, you have no way to add BP "on the fly". I suspect that gdb stops the application before inserting a BP into the running code - therefore it does not work...
4.7.0 allows me to interrupt and to insert breakpoints on the fly using my normal embedded ARM / OpenOCD setup. Leon is correct in assuming that GDB stops the application in order to insert the breakpoint - it's easy to see with OpenOCD as the debug link is slow enough that KDevelop ends up opening whatever file was under the program counter whenever you add or remove a breakpoint while running (which, I might add, is pretty annoying!).
I can't install 4.7.0, as it requires different GLIBC version and some more packages...:-( I do not like to change glibc on my own - too dangerous. And it does not compile for me - compilation errors. I will be really happy to have 4.7.1 patched with the remaining point of stopping gdb... Really happy...
Leon, again - open a new bug report with explicit instructions on how to reproduce your issue with a KDevelop 4.7.1 compiled from latest git 4.7 branch. The initial error discussed in this bug report here _is_ fixed.
I got used not to argue with what my wife says...:-) Report 350916 opened.
Created attachment 93880 [details] kdev-4.7.1-gdb.patch Milian: Sorry to keep posting here, but they are right. The same commit also breaks interrupt and breakpoints on the fly for most setups. I didn't noticed it because I tested on QEMU and there's an older issue when debugging QEMU. There's also some problems with my last patch: 1. The offending commit was meant for OSX and nobody tested my patch on OSX that I know of. 2. The Interrupt command sends SIGINT to some process. I didn't investigate what PID it's getting but obviously not the intended one so it may kill another process if it has the right permissions. Since the offending commit is meant for OSX on this patch I just wrapped it in #if defined(Q_OS_MAC). That restore the 4.7.0 behaviour for Linux and it has no effect on OSX. I tested with both QEMU and the gdbserver example. With QEMU interrupt still don't work (but that's another issue) and with gdbserver everything works.
Sorry for the delay - a lot of urgent work...:-( Yes, I applied the last patch - everything works perfect!!! Fernando!! Thousands of thanks!!!!
No problem. When you get a chance can you post your result on bug #350916 to see if we can get it committed? This one being closed may not get a reaction.