[lldb-dev] Anybody using the GUI?
Greg Clayton via lldb-dev
lldb-dev at lists.llvm.org
Wed Apr 11 11:46:36 PDT 2018
> On Apr 11, 2018, at 11:08 AM, Davide Italiano <dccitaliano at gmail.com> wrote:
> Good day.
> While trying to implement a command in lldb I noticed lldb has this
> awesome `gui` command that opens an ncurses GUI.
> I find it really useful and I wanted to play with it a bit, but I
> wasn't really able to get it working.
> In particular, I tried to press enter on `target create` or `attach`
> but nothing happens.
> Greg, as you wrote the original implementation, can you please explain
> how this is supposed to work? Are you actively interested in
> maintaining this mode?
I really like this mode and would love to see some extra hands on this. I made this quite a while ago and it is definitely a work in progress with many things missing. I really want to work on it, but never had the time as there was always something else.
So I would be really happy to see work done on this and I would like to contribute more to this. I am happy to change anything here as the code that is in there now was my first attempt at doing what I thought was right and I had no input from anyone else, so this is really a blank canvas we can do anything with.
Basics things I tried to do were:
- One window at a time has the focus, and each window gets to make up its own key bindings. Not sure how good of an idea this is, but it is what I came up with. If you type "h" in any window, a dialog pops up and shows you the list of key bindings and what they do
- Arrow keys are used for navigation within the currently selected view. In the source view you can change the highlighted line and hit enter to run to that line, b to set a breakpoint etc. In the variables view, you can expand a variable with right arrow, unexpand it with left arrow and move up and down with the up and down arrows. In the process view you can expand the threads and stack frames.
- Menu items that require no options should just work now (step in/out/over, continue) and ones that do need arguments are incomplete and need work (like target create, attach, launch)
So things I would like to see changed:
- The "Threads" view should remove the top level process and just show all threads
- the current thread with stop reason should automatically be selected and expanded and have frame zero selected
- might be nice to be able to expand a frame and see its variables in this view as this would allow us to see multiple variables for multiple frames and allow the user to hide the Variables view?
- Target->Create should pop up a dialog box and allow user to fill in everything for a target (file, triple (optional), platform (pop up list?), etc)
- Process->Launch should pop up a dialog box and allow user to fill in args, env vars, all launch options
- Process->Attqach should pop up a dialog box and allow user to fill in all attach options (pid, by name, wait for, stop on entry)
- Add a new console view that accepts LLDB commands. Editline doesn't have the callbacks that readline has that allows GDB to shared the terminal with the curses, so it is harder to have a command line in our GUI implementation. It would be great to have a console that can accept commands and drive the debug session
- Add a way to resize any window with some sort of CTRL+ARROW. CTRL+RIGHT would expand the width of the currently selected window by 1 column, CTRL+LEFT would shrink it. Same with CTRL+UP and CTRL+DOWN for the height of stacked views.
We might also want add a dedicated <Stack> view which will show the currently selected thread's frames here and have people select the thread from the "Thread" menu. Not sure if it is better to have all threads in a view that can each be expanded, or dedicated views there the threads list in a view on its own and as you select the thread, then the <Stack> view updates. Or both? All questions and open ended design decisions
So a resounded "yes!!!!" I want to see work done on this and think it is great. It definitely needs discussion so we can agree upon a great interface, but I think it is very close and has great potential!
Let me know your thoughts,
More information about the lldb-dev