<div dir="ltr"><div><div>No Problem, my pleasure to contribute!<br><br></div>Cheers,<br></div>Peifeng Yu<br></div><br><div class="gmail_quote"><div dir="ltr">On Sat, Aug 20, 2016 at 10:51 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, 16 August 2016 21:38:02 CEST Jeremy Murphy wrote:<br>
> I can confirm that it is fixed on the 5.0 branch now. Thanks!<br>
<br>
Thanks a ton Peifeng!<br>
<br>
Cheers,<br>
Kevin<br>
<br>
> Jeremy<br>
><br>
> On 14 August 2016 at 14:17, Aetf <<a href="mailto:7437103@gmail.com" target="_blank">7437103@gmail.com</a>> wrote:<br>
> > Hey Jeremy,<br>
> ><br>
> > On Sat, Aug 13, 2016 at 7:12 PM Jeremy Murphy <<br>
> ><br>
> > <a href="mailto:jeremy.william.murphy@gmail.com" target="_blank">jeremy.william.murphy@gmail.com</a>> wrote:<br>
> >> Hi Peifeng Yu,<br>
> >><br>
> >> have you merged this fix? I just synced with the 5.0 branch and the<br>
> >> verbose debugging output remains.<br>
> ><br>
> > The change is on master now. You can try it on the master branch. I'm not<br>
> > familiar with the develop status on 5.0 branch though, so I'm not sure if<br>
> > I<br>
> > can push directly to that branch. Anyway, I've opened a RR [1] for the fix<br>
> > on 5.0 branch.<br>
> ><br>
> > [1] <a href="https://phabricator.kde.org/D2440" rel="noreferrer" target="_blank">https://phabricator.kde.org/D2440</a><br>
> ><br>
> > Thanks for looking into it, cheers.<br>
> ><br>
> ><br>
> > No problem :)<br>
> ><br>
> > Cheers,<br>
> > Peifeng Yu<br>
> ><br>
> >> Jeremy<br>
> >><br>
> >> On 13 August 2016 at 02:59, Aetf <<a href="mailto:7437103@gmail.com" target="_blank">7437103@gmail.com</a>> wrote:<br>
> >>> Hey,<br>
> >>><br>
> >>> I just checked the code, and realized that actually I've already added<br>
> >>> code showing exit reason to the Debug view as well as debugger console,<br>
> >>> maybe during my first refactor of the code. So I just stopped routing<br>
> >>> console stream into Debug view and everything works perfectly.<br>
> >>><br>
> >>> Now you can get the following exit notifications in the Debug view:<br>
> >>><br>
> >>> Exited with return code: 123<br>
> >>> Exited normally<br>
> >>> Exited on signal SIGXXX<br>
> >>> Program received signal SIGXXX (Human readable name)<br>
> >>><br>
> >>> Cheers,<br>
> >>> Peifeng Yu<br>
> >>><br>
> >>> On Wed, Jul 27, 2016 at 3:38 AM Aetf <<a href="mailto:7437103@gmail.com" target="_blank">7437103@gmail.com</a>> wrote:<br>
> >>>> Sure, but maybe not very soon. My deadline for GSoC is approaching, so<br>
> >>>> I have to focus on LLDB plugin now.<br>
> >>>><br>
> >>>> Cheers,<br>
> >>>> Peifeng Yu<br>
> >>>><br>
> >>>> 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>
> >>>>> On Tuesday, July 26, 2016 7:17:15 PM CEST Aetf wrote:<br>
> >>>>> > The debugger console stream contains not only general debugger<br>
> >>>>><br>
> >>>>> output, but<br>
> >>>>><br>
> >>>>> > also some output generated by commands issued internally by<br>
> >>>>> > kdevelop.<br>
> >>>>> > That's why Jeremy seeing the help text and signal table when using<br>
> >>>>><br>
> >>>>> 4.x<br>
> >>>>><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<br>
> >>>>><br>
> >>>>> console<br>
> >>>>><br>
> >>>>> > stream to Debug view is to get why program stopped, I think there<br>
> >>>>><br>
> >>>>> should be<br>
> >>>>><br>
> >>>>> > a better way than this. As gdb actually reports the stop reason via<br>
> >>>>><br>
> >>>>> MI<br>
> >>>>><br>
> >>>>> > protocol (*stopped,reason="..."), we could use that info to give a<br>
> >>>>><br>
> >>>>> more<br>
> >>>>><br>
> >>>>> > readable output in Debug view, rather than dump all console stream<br>
> >>>>><br>
> >>>>> into<br>
> >>>>><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<br>
> >>>>><br>
> >>>>> was<br>
> >>>>><br>
> >>>>> > > > redirected to application output in commit 609bacd7 (by Kevin<br>
> >>>>><br>
> >>>>> XD), so I<br>
> >>>>><br>
> >>>>> > > > tried to keep the same behavior when cleaning up. Apparently<br>
> >>>>><br>
> >>>>> there's<br>
> >>>>><br>
> >>>>> > > > something I missed.<br>
> >>>>> > > ><br>
> >>>>> > > > We should rethink what kind of outputs we want to show in Debug<br>
> >>>>><br>
> >>>>> view.<br>
> >>>>><br>
> >>>>> > > > Currently, the outputs are routed like:<br>
> >>>>> > > > 1. - Application output -> debugger target<br>
> >>>>><br>
> >>>>> stream -><br>
> >>>>><br>
> >>>>> > > > applicationOutput signal -> Debug View<br>
> >>>>> > > > 2. - Internal command line<br>
> >>>>><br>
> >>>>> -><br>
> >>>>><br>
> >>>>> > > > internalCommandOutput signal -> Debug View, GDB Console<br>
> >>>>> > > > 3. - Internal command output part 1 -> debugger console<br>
> >>>>><br>
> >>>>> stream -><br>
> >>>>><br>
> >>>>> > > > internalCommandOutput signal -> Debug View, GDB Console<br>
> >>>>> > > > 4. - Internal command output part 2 -> debugger result<br>
> >>>>><br>
> >>>>> record -><br>
> >>>>><br>
> >>>>> > > > internalCommandOutput signal -> Debug View, GDB Console<br>
> >>>>> > > > 5. - User command line<br>
> >>>>><br>
> >>>>> -><br>
> >>>>><br>
> >>>>> > > > userCommandOutput signal -> GDB Console<br>
> >>>>> > > > 6. - User command output -> debugger console<br>
> >>>>><br>
> >>>>> stream -><br>
> >>>>><br>
> >>>>> > > > userCommandOutput signal -> GDB Console<br>
> >>>>> > > > 7. - Debugger internal log -> debugger log stream<br>
> >>>>><br>
> >>>>> -><br>
> >>>>><br>
> >>>>> > > > debuggerInternalOutput signal -> GDB Console<br>
> >>>>> > > ><br>
> >>>>> > > > Previous behavior was:<br>
> >>>>> > > > 1. - Application output -> debugger target<br>
> >>>>><br>
> >>>>> stream -><br>
> >>>>><br>
> >>>>> > > > applicationOutput signal -> Debug View<br>
> >>>>> > > > 2. - Internal command line<br>
> >>>>><br>
> >>>>> -><br>
> >>>>><br>
> >>>>> > > > internalCommandOutput signal -> GDB Console<br>
> >>>>> > > > 3. - Internal command output part 1 -> debugger console<br>
> >>>>><br>
> >>>>> stream -><br>
> >>>>><br>
> >>>>> > > > applicationOutput signal -> Debug View<br>
> >>>>> > > > 4. - Internal command output part 2 -> debugger result<br>
> >>>>><br>
> >>>>> record -><br>
> >>>>><br>
> >>>>> > > > internalCommandOutput signal -> GDB Console<br>
> >>>>> > > > 5. - User command line<br>
> >>>>><br>
> >>>>> -><br>
> >>>>><br>
> >>>>> > > > userCommandOutput signal -> GDB Console<br>
> >>>>> > > > 6. - User command output -> debugger console<br>
> >>>>><br>
> >>>>> stream -><br>
> >>>>><br>
> >>>>> > > > userCommandOutput signal -> GDB Console<br>
> >>>>> > > > 7. - Debugger internal log -> debugger log stream<br>
> >>>>><br>
> >>>>> -><br>
> >>>>><br>
> >>>>> > > > debuggerInternalOutput signal -> GDB Console<br>
> >>>>> > > ><br>
> >>>>> > > > In my opinion, we really should only have application output<br>
> >>>>><br>
> >>>>> 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<br>
> >>>>><br>
> >>>>> why.<br>
> >>>>><br>
> >>>>> > > I think the behavior in 609bacd7 was fine, both the application<br>
> >>>>><br>
> >>>>> out +<br>
> >>>>><br>
> >>>>> > > general<br>
> >>>>> > > debugger information was printed in the Debug view. We definitely<br>
> >>>>><br>
> >>>>> don't<br>
> >>>>><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<br>
> >>>>><br>
> >>>>> to dig<br>
> >>>>><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.<br>
> >>>>><br>
> >>>>> I've<br>
> >>>>><br>
> >>>>> > > > > completely abbreviated the actual program output and some<br>
> >>>>><br>
> >>>>> verbose<br>
> >>>>><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<br>
> >>>>><br>
> >>>>> it.<br>
> >>>>><br>
> >>>>> > > > > There is NO WARRANTY, to the extent permitted by law. Type<br>
> >>>>><br>
> >>>>> "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<br>
> >>>>><br>
> >>>>> 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<br>
> >>>>><br>
> >>>>> to. :)<br>
> >>>>><br>
> >>>>> > > > >> Except recently, it started sending verbose GDB output to the<br>
> >>>>><br>
> >>>>> Debug<br>
> >>>>><br>
> >>>>> > > view<br>
> >>>>> > ><br>
> >>>>> > > > >> (along with the actual program output that I would expect)<br>
> >>>>><br>
> >>>>> like so:<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<br>
> >>>>><br>
> >>>>> redistribute it.<br>
> >>>>><br>
> >>>>> > > > >> There is NO WARRANTY, to the extent permitted by law. Type<br>
> >>>>><br>
> >>>>> "show<br>
> >>>>><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<br>
> >>>>><br>
> >>>>> 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 @<br>
> >>>>><br>
> >>>>> "back_inserter"<br>
> >>>>><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<br>
> >>>>><br>
> >>>>> 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<br>
> >>>>><br>
> >>>>> at the<br>
> >>>>><br>
> >>>>> > > > >> moment is GDB 7.11.1, Qt 5.6.1, Frameworks 5.24.0, Plasma<br>
> >>>>><br>
> >>>>> 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<br>
> >>>>><br>
> >>>>> recall<br>
> >>>>><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>
> >>>>> 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>