Review Request: Add Thread and Frame Information on Execution

Milian Wolff mail at milianw.de
Fri Aug 17 18:05:05 UTC 2012



> On June 18, 2012, 12:30 p.m., Milian Wolff wrote:
> > could you please create a unit test for that in the gdb plugin? I guess that should be possible following the steps you outlined above
> 
> David Narváez wrote:
>     How should I write the unit test? Using the breakpoint.kdevelop file found in the tests folder or using the new Unit Test feature in KDevelop?
> 
> Milian Wolff wrote:
>     no, see e.g. kdevelop/debuggers/gdb/unittests/gdbtest.cpp
> 
> David Narváez wrote:
>     I'm having trouble designing the unit test for this. I'm thinking I need to check that the thread and frame information of a BreakInsert command are added during the execCmd method but there's no way to check the internal queue from the unit test. Can somebody help me design the test?
> 
> Niko Sams wrote:
>     Can't you test the actual result? Like a variable value (which has the wrong value if the wrong --thread or --frame is used.
> 
> David Narváez wrote:
>     Eh, still hard to figure out even with your suggestion. The problem is that I need this change to be able to queue both thread-info and break-insert GDB MI commands /when there's no current thread/ which is only at the very begining of the execution; but this change alone does not fix bug 301287, it requires another review request for which the unit test is dead easy and obvious.
>     
>     I actually think the way to ensure this change does not break anything is just running all tests and checking none of them is now failing due to this change, instead of making a unit test for this change alone. Sounds good?
> 
> David Narváez wrote:
>     Bump, I'd really like to close this bug and move on, can anybody comment on my suggestion above?

Sorry for the delay.

Can you maybe extend this patch with the fix for 301287 such that you can add a unit test for that which would also check the patch in here?

Or, even better: What about enquing these commands:

"-select-thread 2"
"-thread-info"

then use a QSignalSpy to get the values of the gdbUserCommandStdout signal of the DebugSession. Then ensure that the last output contained "current-thread-id="2"" - if I'm not mistaken, without your patch this would be "current-thread-id="1"" since --thread 1 would have been added to the -thread-info command.


- Milian


-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
http://git.reviewboard.kde.org/r/105210/#review14828
-----------------------------------------------------------


On June 10, 2012, 11:23 p.m., David Narváez wrote:
> 
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> http://git.reviewboard.kde.org/r/105210/
> -----------------------------------------------------------
> 
> (Updated June 10, 2012, 11:23 p.m.)
> 
> 
> Review request for KDevelop.
> 
> 
> Description
> -------
> 
> Moved the code that adds frame and thread information when not present in the command already from the queueCmd method to the executeCmd method and added some info at the debug strings to make clear that the queued command will be modified upon execution. This is needed in order to be able to queue commands whose information depend on previous commands in the same queue.
> 
> 
> This addresses bug 301287.
>     http://bugs.kde.org/show_bug.cgi?id=301287
> 
> 
> Diffs
> -----
> 
>   debuggers/gdb/debugsession.cpp ed3598e 
> 
> Diff: http://git.reviewboard.kde.org/r/105210/diff/
> 
> 
> Testing
> -------
> 
> 1. Set up a breakpoint in a debug project
> 2. Add a variable to the watch list
> 3. Check the debugging output about the queued command and executed command.
> 
> Previously, these two would be the same. After this patch, the executed command has the --thread and --frame parameters.
> 
> 
> Thanks,
> 
> David Narváez
> 
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/kdevelop-devel/attachments/20120817/a8bd74ff/attachment.html>


More information about the KDevelop-devel mailing list