<div dir="ltr"><div>The debugger console stream contains not only general debugger output, but also some output generated by commands issued internally by kdevelop. That's why Jeremy seeing the help text and signal table when using 4.x version.<br><br>Though it's not hard to restore the behavior without break the applicationOutput signal again, if the only reason for getting console stream to Debug view is to get why program stopped, I think there should be a better way than this. As gdb actually reports the stop reason via MI protocol (*stopped,reason="..."), we could use that info to give a more readable output in Debug view, rather than dump all console stream into Debug view, which is meant to be application output.<br><br></div><div>Cheers,<br></div><div>Peifeng Yu<br></div><div><div><div><br><div class="gmail_quote"><div dir="ltr">On Tue, Jul 26, 2016 at 2:58 PM Kevin Funk <<a href="mailto:kfunk@kde.org">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 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>
><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>
><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 the<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 + general<br>
debugger information was printed in the Debug view. We definitely don't 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 <<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 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>
> > 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, templates,<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 <<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 view<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 mouse<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 tip<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 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>
--<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></div></div></div></div>