<div dir="ltr"><div><div><div><div><div><div><div>Hey,<br><br></div>I just checked the code, and realized that actually I've already added code showing exit reason to the Debug view as well as debugger console, maybe during my first refactor of the code. So I just stopped routing console stream into Debug view and everything works perfectly.<br><br></div><div>Now you can get the following exit notifications in the Debug view:<br><br></div>Exited with return code: 123<br></div>Exited normally<br></div>Exited on signal SIGXXX<br></div>Program received signal SIGXXX (Human readable name)<br><br></div>Cheers,<br></div>Peifeng Yu<br></div><br><div class="gmail_quote"><div dir="ltr">On Wed, Jul 27, 2016 at 3:38 AM Aetf <<a href="mailto:7437103@gmail.com">7437103@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div><div>Sure, but maybe not very soon. My deadline for GSoC is approaching, so I have to focus on LLDB plugin now. <br><br></div>Cheers,<br></div>Peifeng Yu<br></div><br><div class="gmail_quote"><div dir="ltr">On Tue, Jul 26, 2016 at 3:26 PM Kevin Funk <<a href="mailto:kfunk@kde.org" target="_blank">kfunk@kde.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On Tuesday, July 26, 2016 7:17:15 PM CEST Aetf wrote:<br>
> The debugger console stream contains not only general debugger output, but<br>
> also some output generated by commands issued internally by kdevelop.<br>
> That's why Jeremy seeing the help text and signal table when using 4.x<br>
> version.<br>
><br>
> Though it's not hard to restore the behavior without break the<br>
> applicationOutput signal again, if the only reason for getting console<br>
> stream to Debug view is to get why program stopped, I think there should be<br>
> a better way than this. As gdb actually reports the stop reason via MI<br>
> protocol (*stopped,reason="..."), we could use that info to give a more<br>
> readable output in Debug view, rather than dump all console stream into<br>
> Debug view, which is meant to be application output.<br>
<br>
I'm fine with this approach, could you work on that maybe?<br>
<br>
Cheers,<br>
Kevin<br>
<br>
> Cheers,<br>
> Peifeng Yu<br>
><br>
> On Tue, Jul 26, 2016 at 2:58 PM Kevin Funk <<a href="mailto:kfunk@kde.org" target="_blank">kfunk@kde.org</a>> wrote:<br>
> > On Tuesday, July 26, 2016 4:05:51 PM CEST Aetf wrote:<br>
> > > Hi,<br>
> > ><br>
> > > In fact I know this issue. It's because debugger console stream was<br>
> > > redirected to application output in commit 609bacd7 (by Kevin XD), so I<br>
> > > tried to keep the same behavior when cleaning up. Apparently there's<br>
> > > something I missed.<br>
> > ><br>
> > > We should rethink what kind of outputs we want to show in Debug view.<br>
> > ><br>
> > > Currently, the outputs are routed like:<br>
> > >    1. - Application output             -> debugger target stream  -><br>
> > >    applicationOutput signal      -> Debug View<br>
> > >    2. - Internal command line                                     -><br>
> > >    internalCommandOutput signal  -> Debug View, GDB Console<br>
> > >    3. - Internal command output part 1 -> debugger console stream -><br>
> > >    internalCommandOutput signal  -> Debug View, GDB Console<br>
> > >    4. - Internal command output part 2 -> debugger result record  -><br>
> > >    internalCommandOutput signal  -> Debug View, GDB Console<br>
> > >    5. - User command line                                         -><br>
> > >    userCommandOutput signal      -> GDB Console<br>
> > >    6. - User command output            -> debugger console stream -><br>
> > >    userCommandOutput signal      -> GDB Console<br>
> > >    7. - Debugger internal log          -> debugger log stream     -><br>
> > >    debuggerInternalOutput signal -> GDB Console<br>
> > ><br>
> > > Previous behavior was:<br>
> > >    1. - Application output             -> debugger target stream  -><br>
> > >    applicationOutput signal      -> Debug View<br>
> > >    2. - Internal command line                                     -><br>
> > >    internalCommandOutput signal  -> GDB Console<br>
> > >    3. - Internal command output part 1 -> debugger console stream -><br>
> > >    applicationOutput signal      -> Debug View<br>
> > >    4. - Internal command output part 2 -> debugger result record  -><br>
> > >    internalCommandOutput signal  -> GDB Console<br>
> > >    5. - User command line                                         -><br>
> > >    userCommandOutput signal      -> GDB Console<br>
> > >    6. - User command output            -> debugger console stream -><br>
> > >    userCommandOutput signal      -> GDB Console<br>
> > >    7. - Debugger internal log          -> debugger log stream     -><br>
> > >    debuggerInternalOutput signal -> GDB Console<br>
> > ><br>
> > > In my opinion, we really should only have application output routed to<br>
> ><br>
> > the<br>
> ><br>
> > > Debug view. What do you think?<br>
> ><br>
> > If you look at my commit message in 609bacd7:<br>
> ><br>
> > commit 609bacd7f1a94a1aae9518718b5b175ece67141c<br>
> > Author: Kevin Funk <<a href="mailto:kfunk@kde.org" target="_blank">kfunk@kde.org</a>><br>
> > Date:   Fri Jan 15 01:46:15 2016 +0100<br>
> ><br>
> >     GDB: Merge console stream into Debug View<br>
> ><br>
> >     So you get crucial information during debugging, for example:<br>
> ><br>
> >     [Thread debugging using libthread_db enabled]<br>
> >     Using host libthread_db library<br>
> >     "/lib/x86_64-linux-gnu/libthread_db.so.1".<br>
> >     [New Thread 0x7ffff6f4f700 (LWP 19219)]<br>
> >     Program received signal<br>
> >     SIGABRT, Aborted.<br>
> >     0x00007ffff6f85267 in __GI_raise (sig=sig@entry=6) at<br>
> >     ../sysdeps/unix/sysv/linux/raise.c:55<br>
> ><br>
> > => There needs to some way to see whether the program stopped, and why.<br>
> ><br>
> > I think the behavior in 609bacd7 was fine, both the application out +<br>
> > general<br>
> > debugger information was printed in the Debug view. We definitely don't<br>
> > want<br>
> > to see the GDB MI communication, though.<br>
> ><br>
> > Can't we get this behavior back?<br>
> ><br>
> > Unfortunately I'm not really on top of what you changed; I'd need to dig<br>
> > through your changes.<br>
> ><br>
> > Cheers,<br>
> > Kevin<br>
> ><br>
> > > Cheers,<br>
> > ><br>
> > > Peifeng Yu<br>
> > ><br>
> > > On Tue, Jul 26, 2016, 03:12 Jeremy Murphy <<br>
> ><br>
> > <a href="mailto:jeremy.william.murphy@gmail.com" target="_blank">jeremy.william.murphy@gmail.com</a>><br>
> ><br>
> > > wrote:<br>
> > > > I just reverted to 4.90.91 and the output is quite different. I've<br>
> > > > completely abbreviated the actual program output and some verbose<br>
> > > > templates<br>
> > > > in the line where it hits a breakpoint:<br>
> > > ><br>
> > > ><br>
> > > > GNU gdb (Gentoo 7.11.1 vanilla) 7.11.1<br>
> > > > Copyright (C) 2016 Free Software Foundation, Inc.<br>
> > > > License GPLv3+: GNU GPL version 3 or later <<br>
> > > > <a href="http://gnu.org/licenses/gpl.html" rel="noreferrer" target="_blank">http://gnu.org/licenses/gpl.html</a>><br>
> > > > This is free software: you are free to change and redistribute it.<br>
> > > > There is NO WARRANTY, to the extent permitted by law.  Type "show<br>
> ><br>
> > copying"<br>
> ><br>
> > > > and "show warranty" for details.<br>
> > > > This GDB was configured as "x86_64-pc-linux-gnu".<br>
> > > > Type "show configuration" for configuration details.<br>
> > > > For bug reporting instructions, please see:<br>
> > > > <<a href="https://bugs.gentoo.org/" rel="noreferrer" target="_blank">https://bugs.gentoo.org/</a>>.<br>
> > > > Find the GDB manual and other documentation resources online at:<br>
> > > > <<a href="http://www.gnu.org/software/gdb/documentation/" rel="noreferrer" target="_blank">http://www.gnu.org/software/gdb/documentation/</a>>.<br>
> > > > For help, type "help".<br>
> > > > Type "apropos word" to search for commands related to "word".<br>
> > > > Signal        Stop Print Pass to program Description<br>
> > > > SIG32         No No Yes Real-time event 32<br>
> > > > Signal        Stop Print Pass to program Description<br>
> > > > SIG41         No No Yes Real-time event 41<br>
> > > > Signal        Stop Print Pass to program Description<br>
> > > > SIG42         No No Yes Real-time event 42<br>
> > > > Signal        Stop Print Pass to program Description<br>
> > > > SIG43         No No Yes Real-time event 43<br>
> > > > [Thread debugging using libthread_db enabled]<br>
> > > > Using host libthread_db library "/lib64/libthread_db.so.1".<br>
> > > ><br>
> > > > ---- my program output ---<br>
> > > ><br>
> > > > Breakpoint 1, footprinter::create_split_segments<...templates,<br>
> ><br>
> > templates,<br>
> ><br>
> > > > templates...>../footprinter.hpp:146<br>
> > > > 146    vector<segment_data<double>> segments;<br>
> > > ><br>
> > > ><br>
> > > > Cheers.<br>
> > > ><br>
> > > > Jeremy<br>
> > > ><br>
> > > ><br>
> > > > On 26 July 2016 at 16:02, Jeremy Murphy <<br>
> ><br>
> > <a href="mailto:jeremy.william.murphy@gmail.com" target="_blank">jeremy.william.murphy@gmail.com</a>><br>
> ><br>
> > > > wrote:<br>
> > > >> Hi everyone,<br>
> > > >><br>
> > > >> I'm loving KDevelop 5.0 alpha/beta/gamma whatever it is up to.  :)<br>
> > > >><br>
> > > >> Except recently, it started sending verbose GDB output to the Debug<br>
> ><br>
> > view<br>
> ><br>
> > > >> (along with the actual program output that I would expect) like so:<br>
> > > >><br>
> > > >><br>
> > > >> (gdb) 1-gdb-show version<br>
> > > >> GNU gdb (Gentoo 7.11.1 vanilla) 7.11.1<br>
> > > >> Copyright (C) 2016 Free Software Foundation, Inc.<br>
> > > >> License GPLv3+: GNU GPL version 3 or later <<br>
> > > >> <a href="http://gnu.org/licenses/gpl.html" rel="noreferrer" target="_blank">http://gnu.org/licenses/gpl.html</a>><br>
> > > >> This is free software: you are free to change and redistribute it.<br>
> > > >> There is NO WARRANTY, to the extent permitted by law.  Type "show<br>
> > > >> copying"<br>
> > > >> and "show warranty" for details.<br>
> > > >> This GDB was configured as "x86_64-pc-linux-gnu".<br>
> > > >> Type "show configuration" for configuration details.<br>
> > > >> For bug reporting instructions, please see:<br>
> > > >> <<a href="https://bugs.gentoo.org/" rel="noreferrer" target="_blank">https://bugs.gentoo.org/</a>>.<br>
> > > >> Find the GDB manual and other documentation resources online at:<br>
> > > >> <<a href="http://www.gnu.org/software/gdb/documentation/" rel="noreferrer" target="_blank">http://www.gnu.org/software/gdb/documentation/</a>>.<br>
> > > >> For help, type "help".<br>
> > > >> Type "apropos word" to search for commands related to "word".<br>
> > > >> 1^done<br>
> > > >> (gdb) 2-gdb-set width 0<br>
> > > >> 2^done<br>
> > > >><br>
> > > >> ---8<--- ~200 lines of output ---8<---<br>
> > > >><br>
> > > >> (gdb) 129-var-create --thread 1 --frame 0 var113 @ "typename"<br>
> > > >> 129^error,msg="-var-create: unable to create variable object"<br>
> > > >> (gdb) 130-var-create --thread 1 --frame 0 var114 @ "back_inserter"<br>
> > > >> 130^error,msg="-var-create: unable to create variable object"<br>
> > > >><br>
> > > >><br>
> > > >> It sends the messages when I run debug, obviously, but also when I<br>
> ><br>
> > mouse<br>
> ><br>
> > > >> over variables as the last couple of lines are an example of.<br>
> > > >><br>
> > > >> I'm using the latest releases of just about everything, which at the<br>
> > > >> moment is GDB 7.11.1, Qt 5.6.1, Frameworks 5.24.0, Plasma 5.7.2, and<br>
> ><br>
> > tip<br>
> ><br>
> > > >> of<br>
> > > >> the 5.0 branch for KDevelop and KDevPlatform.<br>
> > > >><br>
> > > >> Is this a known issue or am I the lucky discoverer? I can't recall<br>
> > > >> exactly when I first noticed it, sorry, but it must have been<br>
> ><br>
> > recently.<br>
> ><br>
> > > >> Thanks, cheers.<br>
> > > >><br>
> > > >> Jeremy<br>
> > > ><br>
> > > > _______________________________________________<br>
> > > > KDevelop-devel mailing list<br>
> > > > <a href="mailto:KDevelop-devel@kde.org" target="_blank">KDevelop-devel@kde.org</a><br>
> > > > <a href="https://mail.kde.org/mailman/listinfo/kdevelop-devel" rel="noreferrer" target="_blank">https://mail.kde.org/mailman/listinfo/kdevelop-devel</a><br>
> ><br>
> > --<br>
> > Kevin Funk | <a href="mailto:kfunk@kde.org" target="_blank">kfunk@kde.org</a> | <a href="http://kfunk.org" rel="noreferrer" target="_blank">http://kfunk.org</a><br>
<br>
<br>
--<br>
Kevin Funk | <a href="mailto:kfunk@kde.org" target="_blank">kfunk@kde.org</a> | <a href="http://kfunk.org" rel="noreferrer" target="_blank">http://kfunk.org</a></blockquote></div></blockquote></div>