Debug view receives verbose GDB messages
Aetf
7437103 at gmail.com
Sun Aug 14 04:17:57 UTC 2016
Hey Jeremy,
On Sat, Aug 13, 2016 at 7:12 PM Jeremy Murphy <
jeremy.william.murphy at gmail.com> wrote:
> Hi Peifeng Yu,
>
> have you merged this fix? I just synced with the 5.0 branch and the
> verbose debugging output remains.
>
The change is on master now. You can try it on the master branch. I'm not
familiar with the develop status on 5.0 branch though, so I'm not sure if I
can push directly to that branch. Anyway, I've opened a RR [1] for the fix
on 5.0 branch.
[1] https://phabricator.kde.org/D2440
Thanks for looking into it, cheers.
>
No problem :)
Cheers,
Peifeng Yu
> 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/20160814/b009cdce/attachment-0001.html>
More information about the KDevelop-devel
mailing list