Debug view receives verbose GDB messages
Aetf
7437103 at gmail.com
Fri Aug 12 16:59:35 UTC 2016
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/20160812/d47d079e/attachment-0001.html>
More information about the KDevelop-devel
mailing list