Debug view receives verbose GDB messages
Jeremy Murphy
jeremy.william.murphy at gmail.com
Sat Aug 13 11:12:34 UTC 2016
Hi Peifeng Yu,
have you merged this fix? I just synced with the 5.0 branch and the
verbose debugging output remains.
Thanks for looking into it, cheers.
Jeremy
On 13 August 2016 at 02:59, Aetf <7437103 at gmail.com> wrote:
> Hey,
>
> 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.
>
> Now you can get the following exit notifications in the Debug view:
>
> Exited with return code: 123
> Exited normally
> Exited on signal SIGXXX
> Program received signal SIGXXX (Human readable name)
>
> Cheers,
> Peifeng Yu
>
> On Wed, Jul 27, 2016 at 3:38 AM Aetf <7437103 at gmail.com> wrote:
>
>> Sure, but maybe not very soon. My deadline for GSoC is approaching, so I
>> have to focus on LLDB plugin now.
>>
>> Cheers,
>> Peifeng Yu
>>
>> On Tue, Jul 26, 2016 at 3:26 PM Kevin Funk <kfunk at kde.org> wrote:
>>
>>> On Tuesday, July 26, 2016 7:17:15 PM CEST Aetf wrote:
>>> > 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.
>>> >
>>> > 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.
>>>
>>> I'm fine with this approach, could you work on that maybe?
>>>
>>> Cheers,
>>> Kevin
>>>
>>> > Cheers,
>>> > Peifeng Yu
>>> >
>>> > On Tue, Jul 26, 2016 at 2:58 PM Kevin Funk <kfunk at kde.org> wrote:
>>> > > On Tuesday, July 26, 2016 4:05:51 PM CEST Aetf wrote:
>>> > > > Hi,
>>> > > >
>>> > > > In fact I know this issue. It's because debugger console stream was
>>> > > > redirected to application output in commit 609bacd7 (by Kevin XD),
>>> so I
>>> > > > tried to keep the same behavior when cleaning up. Apparently
>>> there's
>>> > > > something I missed.
>>> > > >
>>> > > > We should rethink what kind of outputs we want to show in Debug
>>> view.
>>> > > >
>>> > > > Currently, the outputs are routed like:
>>> > > > 1. - Application output -> debugger target stream
>>> ->
>>> > > > applicationOutput signal -> Debug View
>>> > > > 2. - Internal command line
>>> ->
>>> > > > internalCommandOutput signal -> Debug View, GDB Console
>>> > > > 3. - Internal command output part 1 -> debugger console stream
>>> ->
>>> > > > internalCommandOutput signal -> Debug View, GDB Console
>>> > > > 4. - Internal command output part 2 -> debugger result record
>>> ->
>>> > > > internalCommandOutput signal -> Debug View, GDB Console
>>> > > > 5. - User command line
>>> ->
>>> > > > userCommandOutput signal -> GDB Console
>>> > > > 6. - User command output -> debugger console stream
>>> ->
>>> > > > userCommandOutput signal -> GDB Console
>>> > > > 7. - Debugger internal log -> debugger log stream
>>> ->
>>> > > > debuggerInternalOutput signal -> GDB Console
>>> > > >
>>> > > > Previous behavior was:
>>> > > > 1. - Application output -> debugger target stream
>>> ->
>>> > > > applicationOutput signal -> Debug View
>>> > > > 2. - Internal command line
>>> ->
>>> > > > internalCommandOutput signal -> GDB Console
>>> > > > 3. - Internal command output part 1 -> debugger console stream
>>> ->
>>> > > > applicationOutput signal -> Debug View
>>> > > > 4. - Internal command output part 2 -> debugger result record
>>> ->
>>> > > > internalCommandOutput signal -> GDB Console
>>> > > > 5. - User command line
>>> ->
>>> > > > userCommandOutput signal -> GDB Console
>>> > > > 6. - User command output -> debugger console stream
>>> ->
>>> > > > userCommandOutput signal -> GDB Console
>>> > > > 7. - Debugger internal log -> debugger log stream
>>> ->
>>> > > > debuggerInternalOutput signal -> GDB Console
>>> > > >
>>> > > > In my opinion, we really should only have application output
>>> routed to
>>> > >
>>> > > the
>>> > >
>>> > > > Debug view. What do you think?
>>> > >
>>> > > If you look at my commit message in 609bacd7:
>>> > >
>>> > > commit 609bacd7f1a94a1aae9518718b5b175ece67141c
>>> > > Author: Kevin Funk <kfunk at kde.org>
>>> > > Date: Fri Jan 15 01:46:15 2016 +0100
>>> > >
>>> > > GDB: Merge console stream into Debug View
>>> > >
>>> > > So you get crucial information during debugging, for example:
>>> > >
>>> > > [Thread debugging using libthread_db enabled]
>>> > > Using host libthread_db library
>>> > > "/lib/x86_64-linux-gnu/libthread_db.so.1".
>>> > > [New Thread 0x7ffff6f4f700 (LWP 19219)]
>>> > > Program received signal
>>> > > SIGABRT, Aborted.
>>> > > 0x00007ffff6f85267 in __GI_raise (sig=sig at entry=6) at
>>> > > ../sysdeps/unix/sysv/linux/raise.c:55
>>> > >
>>> > > => There needs to some way to see whether the program stopped, and
>>> why.
>>> > >
>>> > > I think the behavior in 609bacd7 was fine, both the application out +
>>> > > general
>>> > > debugger information was printed in the Debug view. We definitely
>>> don't
>>> > > want
>>> > > to see the GDB MI communication, though.
>>> > >
>>> > > Can't we get this behavior back?
>>> > >
>>> > > Unfortunately I'm not really on top of what you changed; I'd need to
>>> dig
>>> > > through your changes.
>>> > >
>>> > > Cheers,
>>> > > Kevin
>>> > >
>>> > > > Cheers,
>>> > > >
>>> > > > Peifeng Yu
>>> > > >
>>> > > > On Tue, Jul 26, 2016, 03:12 Jeremy Murphy <
>>> > >
>>> > > jeremy.william.murphy at gmail.com>
>>> > >
>>> > > > wrote:
>>> > > > > I just reverted to 4.90.91 and the output is quite different.
>>> I've
>>> > > > > completely abbreviated the actual program output and some verbose
>>> > > > > templates
>>> > > > > in the line where it hits a breakpoint:
>>> > > > >
>>> > > > >
>>> > > > > GNU gdb (Gentoo 7.11.1 vanilla) 7.11.1
>>> > > > > Copyright (C) 2016 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 "x86_64-pc-linux-gnu".
>>> > > > > Type "show configuration" for configuration details.
>>> > > > > For bug reporting instructions, please see:
>>> > > > > <https://bugs.gentoo.org/>.
>>> > > > > 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".
>>> > > > > Signal Stop Print Pass to program Description
>>> > > > > SIG32 No No Yes Real-time event 32
>>> > > > > Signal Stop Print Pass to program Description
>>> > > > > SIG41 No No Yes Real-time event 41
>>> > > > > Signal Stop Print Pass to program Description
>>> > > > > SIG42 No No Yes Real-time event 42
>>> > > > > Signal Stop Print Pass to program Description
>>> > > > > SIG43 No No Yes Real-time event 43
>>> > > > > [Thread debugging using libthread_db enabled]
>>> > > > > Using host libthread_db library "/lib64/libthread_db.so.1".
>>> > > > >
>>> > > > > ---- my program output ---
>>> > > > >
>>> > > > > Breakpoint 1, footprinter::create_split_segments<...templates,
>>> > >
>>> > > templates,
>>> > >
>>> > > > > templates...>../footprinter.hpp:146
>>> > > > > 146 vector<segment_data<double>> segments;
>>> > > > >
>>> > > > >
>>> > > > > Cheers.
>>> > > > >
>>> > > > > Jeremy
>>> > > > >
>>> > > > >
>>> > > > > On 26 July 2016 at 16:02, Jeremy Murphy <
>>> > >
>>> > > jeremy.william.murphy at gmail.com>
>>> > >
>>> > > > > wrote:
>>> > > > >> Hi everyone,
>>> > > > >>
>>> > > > >> I'm loving KDevelop 5.0 alpha/beta/gamma whatever it is up to.
>>> :)
>>> > > > >>
>>> > > > >> Except recently, it started sending verbose GDB output to the
>>> Debug
>>> > >
>>> > > view
>>> > >
>>> > > > >> (along with the actual program output that I would expect) like
>>> so:
>>> > > > >>
>>> > > > >>
>>> > > > >> (gdb) 1-gdb-show version
>>> > > > >> GNU gdb (Gentoo 7.11.1 vanilla) 7.11.1
>>> > > > >> Copyright (C) 2016 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 "x86_64-pc-linux-gnu".
>>> > > > >> Type "show configuration" for configuration details.
>>> > > > >> For bug reporting instructions, please see:
>>> > > > >> <https://bugs.gentoo.org/>.
>>> > > > >> 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".
>>> > > > >> 1^done
>>> > > > >> (gdb) 2-gdb-set width 0
>>> > > > >> 2^done
>>> > > > >>
>>> > > > >> ---8<--- ~200 lines of output ---8<---
>>> > > > >>
>>> > > > >> (gdb) 129-var-create --thread 1 --frame 0 var113 @ "typename"
>>> > > > >> 129^error,msg="-var-create: unable to create variable object"
>>> > > > >> (gdb) 130-var-create --thread 1 --frame 0 var114 @
>>> "back_inserter"
>>> > > > >> 130^error,msg="-var-create: unable to create variable object"
>>> > > > >>
>>> > > > >>
>>> > > > >> It sends the messages when I run debug, obviously, but also
>>> when I
>>> > >
>>> > > mouse
>>> > >
>>> > > > >> over variables as the last couple of lines are an example of.
>>> > > > >>
>>> > > > >> I'm using the latest releases of just about everything, which
>>> at the
>>> > > > >> moment is GDB 7.11.1, Qt 5.6.1, Frameworks 5.24.0, Plasma
>>> 5.7.2, and
>>> > >
>>> > > tip
>>> > >
>>> > > > >> of
>>> > > > >> the 5.0 branch for KDevelop and KDevPlatform.
>>> > > > >>
>>> > > > >> Is this a known issue or am I the lucky discoverer? I can't
>>> recall
>>> > > > >> exactly when I first noticed it, sorry, but it must have been
>>> > >
>>> > > recently.
>>> > >
>>> > > > >> Thanks, cheers.
>>> > > > >>
>>> > > > >> Jeremy
>>> > > > >
>>> > > > > _______________________________________________
>>> > > > > KDevelop-devel mailing list
>>> > > > > KDevelop-devel at kde.org
>>> > > > > https://mail.kde.org/mailman/listinfo/kdevelop-devel
>>> > >
>>> > > --
>>> > > Kevin Funk | kfunk at kde.org | http://kfunk.org
>>>
>>>
>>> --
>>> Kevin Funk | kfunk at kde.org | http://kfunk.org
>>
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/kdevelop-devel/attachments/20160813/7195c100/attachment-0001.html>
More information about the KDevelop-devel
mailing list