Debugging features

[eidheim]

Feel free to post debugging features you are missing and would like to see in juCi++ here. Just keep in mind that you can use Run Command in the Debug menu to pass commands to the lldb debugger, and we most likely do not need GUI items for every possible lldb command.

[milleniumbug]

Honestly I'd like to see debugging work, depending on the lldb/clang version, the debugger can get unstable and crash juCi++. But separating to another process is probably too much work so I understand if it can't be done.

Speaking of what could be done, I'd like to see

• being able to view several variables without hovering over variables or selecting the variable from the menu - this is so I can observe all of them and check if any of them changes
• extension of the above feature, diffing between the previous display, so the changes of variable state are highlighted
• equivalent of "autos" feature from Visual Studio, where the debugger window displays all the local variables that are in scope.
• being able to create breakpoints by clicking on the line number, like most IDEs are able to do.

[eidheim]

Thank you. Regarding lldb crashes, they are mostly related to the debug builds compiled with some optimisation -O option. Removing optimisation solves most of the crashes. Also, if there are other crashes, this will likely be improved in future versions of lldb.

[epsilon-phase]

I think it might be easier to work in some sort of DebuggerProvider that runs the underlying debugger process and interacts with the editor to send appropriate commands to it.

For example, you mouse over a variable in the function where the code is paused, it sends the request to the debugger through the generic API and the editor displays it in the popup box.

I don't like having to build the debugger into the editor because the the debugger seem to have issues with stability, and passing -O2 shouldn't cause the editor to crash.

If you're open to it, I could try taking a look at it, though I've not done much work on the codebase for Juci++, all it should take is a bit of piping, so I think I ought to be able to accomplish this.

So does that sound appealing to you at all @eidheim?

[eidheim]

@jaked122 I'm not worried about the lldb crashes when debugging with optimisation flags as this will be improved with later liblldb versions. The same crashes happen in lldb as well, since lldb is using liblldb. Just keep issuing crash reports to the liblldb project:)

The main problem with running lldb in a separate process is the additional layer of overhead which will slow things down and require additional memory. The current solution, using liblldb directly, is the best solution and it will be the best solution in the years to come. In this case, I think it is not worth our time to create and maintain a larger workaround that we soon have to remove anyway when liblldb is stable.

On a side note, if possible, I would disable any optimisations (actually using -Og is an option, although I have not tried this flag) when debugging, since optimisations typically interfere with debugging. However, having said that, it is possible to enable optimisations, but add additional flags that remove specific optimisations that affects debugging. It might be worth looking into this if debugging with optimisation is important in your project.

[epsilon-phase]

@eidheim that's fair enough, I don't think optimization should be an issue in my projects for a bit anyway, not during the periods when I'm debugging anyway.

[junrrein]

I would like to have a "watch variables" window/panel, where I can add specific variables I want to watch. Something interesting that can be done here is highlighting which variables changed since the last step/breakpoint.

Support for conditional breakpoints would be great.

Actually, for inspiration, I suggest looking at Visual Studio Code's debugging UX/features. I think they've done some good work on it.

[junrrein]

Another reason I would like to see a "watch variables" panel is that a lot of times some classes/structs have members with lots of elements (like a vector) and it's not possible to view all of it in the popup. For example:

[eidheim]

I've had the debugging GUI on my TODO list for quite some time. Hopefully, I'll jump into it during the summer. In the meanwhile, please use Run Command in the Debug menu to pass commands directly to the running lldb server. See https://lldb.llvm.org/lldb-gdb.html for examples of the most commonly used lldb commands.

[eidheim]

Also, if someone would like to program the debugging GUI, feel free to do so and create a PR on this. I could then focus on the liblldb specific code needed to update the values in the debugging GUI. At least this would speed up the process:)

I guess the two most needed GUI components are frame variables and watch points.

[ratchetfreak]

A very much nice to have feature is a graph visualization of your objects memory. So you can get a easy overview of your state even when it's spread across a dozen different allocated objects.

Besides that big scale it's also nice when debugging data structures when you can actually see the pointers pointing to the correct other nodes.

[h-g-s]

Being able to watch a list of variables, including STL containers, would be great. For STL containers Kdevelop guys did a good job, you can open a treeview to inspect contents.

[eidheim]

I did have a go at making a hierarchy list of frame variable values, but it was sadly not trivial with liblldb. I'll probably try again though when I have time. But feel free to play around with liblldb, if you find a way to do it easily let me know:) However, take note that liblldb is barely documented!

Some help might be in the plugin that Rust uses for lldb: https://github.com/rust-lang/rust/blob/master/src/etc/lldb_rust_formatters.py. Might be that we can make use of a plugin instead of using liblldb directly, or at least learn how to do it in liblldb by studying the plugin code.

The difference with how other IDE's are doing it and juCi++, is that we use the liblldb library directly for minimal resource use and speed.

[szymonk211]

@eidheim did you consider placing tree view inside tooltip window? I've seen something like this in atom notepad: Maybe inside that window there could be placed some kind of text field that let the user specify which element of this big vector he wants to see? This would solve @junrrein problem with big vector tooltip window. In this way you wouldn't have to create a tree view for every variable in given scope, but only for variables user place cursor at. I can come up with some code (at least for the gui elements) if you like the idea.

[eidheim]

@szymonk211 help on this issue is much appreciated. I think the first step would be to create a tree view below the directory/file view that shows the frame variables and their values. The main problem though is to receive the values that should be placed in this tree view.

The information that is shown in the tooltips is autogenerated by lldb, so one would have to instead read the values in another way. A good start could be to find a way to extract std::vector<int> element values and the contents of a std::string using liblldb, and then take it from there. Although one would have to check if it works both on clang and gcc compiled code.