Anybody using the GUI?

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?

Thanks!

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,

Greg Clayton

And yes many people I know are using this including myself.

Hi Greg,

We're more than a year later and I haven't seen any development on the
GUI. While I personally thing this could be a really cool feature,
I've never been able to use it because it's missing too many thing to
be useful for now. When I talk to people that know about this feature,
I hear either frustration or disappointment that it doesn't work
(yet). I (personally) haven't found anyone that is actively using it.
As such, can we remove it until we have resources to do it right and
provide our users with something they can rely on?

Thanks,
Jonas

From what I can tell the main thing this is missing is a Console window. I imagine hosting a full console window inside a ncurses sub window would be a pain if there isn't a pre-built widget for that. But maybe it would be easier to open another terminal window and connect the debuggers I/O channels to that console. We already know how to open another terminal - we use that for the "launch in a separate terminal". So you could reuse that. That might be a cheap way to fill in the main missing piece.

Jim

I’ve used it every now and then. It seems to work well enough for simple things (stepping through assembly and looking at registers iirc – but maybe it was stepping through code and looking at variables).

I know many people use it. They tend to drop in and use it, and then drop back out. I don't see how taking this out will help us do anything about fixing things. I created this in hopes people would jump on and help to make it. I could _never_ get the ok to work on it when I was at Apple. Still haven't had time at Facebook. But I would like people to help improve it. It won't take much to make it better, just needs more than 1 person to try it out and help improve it. So I would vote to keep it in as we do have people that are using it.

I’m also in favour of keeping the GUI around. It’s not perfect, but at least in a usable state and not a huge maintenance burden from what I can see.

- Raphael

Count me among those who didn't even know it existed - is it even packaged in any of the official LLVM (.deb) packages? I haven't noticed it as part of the MacPorts ports for LLVM/Clang either...

R.

The GUI is built into lldb, it is not a separate entity.

Jim

Oh, right, so a "AUI" or "CUI" rather than something properly graphical. Sorry, not very useful to me.

R.

I’d be very interested in using lldb in my regular workflow… but, I’m currently using cgdb because its single key mode is ready convenient for common operations:

f - finish
s - step
n - next
d - down
u - up

rr record $exe $args
rr replay -d cgdb
# happy debugging
# rm -r ~/.local/share/rr when it gets too bloated

I did try gui several times in the past but did not succeed.