Graphical lldb

Hello

I want to create a graphical UI to lldb in cocoa-qt so I could see data structures graphically, like lines as 2D lines, 1D graphs and so on.

So as a first step I need to replace lldb tool text input and output with a graphical window alternative.

I mean replacing the text command line with a text edit widget like Xcode does.

What is the best way(more elegant, less work) to do this?.

I have lots of experience making graphical programs but little handling terminal ones.

Jose,

that sounds like a really cool idea!
One question that comes to mind, though: do you need to have the LLDB console in a custom window?
If you package your data-strcuture visualization as a set of custom commands that can be used from within LLDB, and that then talk to (say) a cocoa-qt based server, then you could even use these commands from inside Xcode.
It also means you don’t have to worry about I/O redirection, which can be a hassle.

Sean

There is currently some example of GUI from the command line with the lldb/examples/python/lldbtk.py.

The quickest way to do this would be to use python, which can already bridge to objective C, and drive the GUI from python as a new LLDB command. See the example code:

% svn cat http://llvm.org/svn/llvm-project/lldb/trunk/examples/python/lldbtk.py

What this does is it installs new lldb command line commands "tk-variables", "tk-process" and "tk-target" which can be used anytime from within LLDB. When you execute the command, the GUI will display itself and way for your to close the window, and then it exits.

So you don't have to re-skin LLDB at all of you don't want to.

If you still want to write your own GUI, I would suggest you open a pseudo terminal (pty) and your write into stdin of the master side, and listen for output on the master and give the slave side to lldb by calling:

SBDebugger::SetInputFileHandle(...)
SBDebugger::SetOutputFileHandle(...)
SBDebugger::SetErrorFileHandle(...)

Then whenever you get text from your text widget, you write it into the master side of the pty which gives it to LLDB when you run the command interpreter. If you want more details on that let me know.

Greg

I'd suggest looking at http://www.codeblocks.org
There is no lldb plug for codeblocks but you could create one.

http://forums.codeblocks.org/index.php?topic=16393.0;prev_next=prev

Thanks,
J.R.

Found this too.
https://github.com/meeloo/xspray

Thanks,
J.R.

Oh, sorry, I was answering private messages to Greg instead of the
list, I feel so newbie.

Hello Sean,

Yes, I think so, I need it in a custom window. I have done tests using matplotlib and script, but it lacks interoperability, graphical reaction to mouse-tablet, 3d mouse or trackpad input, a "reactive surface".

Here is what I want to do: I use vectors or arrays all around my code:

1D vectors like indices of another vector, or sound samples, or tablet pressure, or type identifiers.

2D vectors for x, y coordinates of vertices, or image segmentation information.

3D vectors, for 3D points.

A mix of all the above, for example a path is created as a 1D index that points to a 2D vector that holds the path element type like CIRCLE, ARC, LINE, BEZIER CUBIC,BEZIER CUADRATIC and another index that points to the coordinates of the (line, arc or bezier) elements.

Right now for debugging I have to painfully follow those vectors and mentally translating and tracking those in my head, which is extremely slow, error prone, and uses rational power that I should use in other things.

We have tens of millions of visual sensors and a tremendous parallel computing force in our eyes and brain to analyze them in less than a second and with a text debugger we are not using them at all.

So I need a tool that helps me debugging my programs, that displays a 1D vector for example as a series of rectangles with different colors, so for example CIRCLE = RED, ARC = BLUE, LINE = GREEEN. and so on so just watching at a glance gives me the path information.

Now when I click on the second red rectangle, it could display me a circle in a canvas, or the line, or the bezier rectangle that I clicked.

Now, this is very easy for me, I have experience making that happen. What I don't have experience is with the lldb environment.

So I want to have something working as fast as possible, then gradually replace text commands with graphical ones, like "Step Into" icons.

But this is the least important thing, at first I will use just custom text commands, but I need to display a reactive canvas that could display data like all the vectors and generate those commands when I click on those.

Just emulating the input and output of text and using the same Driver of lldb-tool should be easy.

PS: by "reactive surface" I mean the ability to navigate the data in
the frame very fast for example using two fingers and the "Magic
trackpad".

Graphically I could see all the local variables, the pointers, and
when it identifies a 1D, 2D, 3D vector type it displays the first 50
elements for example as rectangles,with colors, or numbers if it is an
index, or the "pointed elements" of another vector if it is an index.

Then with just a gesture I could see the next 50 elements of the
vectors, and so on.

I should probably have to make a video to better explain myself.

I am looking at the emulation work and it looks probably too much work if I am going to discard it later.

It would be better if I could mess with the command list directly.

Right now I have to create a terminal emulator, so I could send commands, then those commands are parsed and then the output or errors are written in text form in the terminal.

How could I get all the possible commands that are possible in lldb and skip the parsing altogether?.

I mean just telling lldb "execute command ‘this’ ", ‘this’ being a callback, not a text string, and being c++, not python.

If I use a menu or other graphical method to access commands, lldb does not need to interpret anything. or does it?

Parameters have to be given in a single line of text or I could split it with strings identifiers like llvm does?

I will be looking at the code to solve this questions…

@J.R.Heisey. Yes, Xspray includes things that I want to add in my debugging.

The problem with xspray is the UI library it uses is called libNUI, that could not compete against environments like cocoa or Qt and it is very very poorly documented. Sebastien Metrot used it because he created LibNUI and understands it.

The UI is also unintentionally obfuscated, using things like function macros inside function macros inside function macros that make it extremely difficult to follow with the debugger and understand the code.

Lldb code is much better structured, and in few days looking at the code I understand it much better that this libNUI thing.

Ok, I think I found what I was looking for.

In
CommandInterpreter::Initialize ()

All the possible commands are initialized with the official name and
the alias of each command.

In an interactive session an IOHandler is created, and a host thread
is also created.

I suppose the host handles the signal interruptions and displaying the
error and output files on the screen.

Meanwhile the IOHandler gets the input and matches the input line with
all the stored commands to execute them.

So what I need to do is after initialization read all the commands and
create a UI menu item for each one of them, each one with an icon or
something. Then I could use the same input code that interactive mode
uses in order to execute them.

What I need to understand better is how additional subcommands are specified.

Ok, I think I found what I was looking for.

In
CommandInterpreter::Initialize ()

All the possible commands are initialized with the official name and
the alias of each command.

In an interactive session an IOHandler is created, and a host thread
is also created.

I suppose the host handles the signal interruptions and displaying the
error and output files on the screen.

Meanwhile the IOHandler gets the input and matches the input line with
all the stored commands to execute them.

So what I need to do is after initialization read all the commands and
create a UI menu item for each one of them, each one with an icon or
something. Then I could use the same input code that interactive mode
uses in order to execute them.

What I need to understand better is how additional subcommands are specified.

Greg already obliquely asked this, but why do you want your GUI have to model the way the command interpreter commands are laid out?

In general the way you would organize things in a GUI application and in a command hierarchy are pretty different. So I'm not sure starting with the command interpreter layout is the best way to design the GUI...

After all, you can do pretty much everything with the SB API's that you can do with the command interpreter, and they leave you free to organize things as makes sense for your application...

Jim

@jingham: Oh, simple. I just wanted a better way to handle the errors
and output of lldb that just having a text file stream that I have to
parse to understand, because I want the GUI to understand some things
like an error happened or not and I just can't stand parsing stuff.

Anyway, I have read a lot of code meanwhile and I understand lldb much
better now.

About the SB API's, it forces me to use python, but I am using C++ so
I prefer to use the c++ equivalent if possible. Not that it looks too
hard as the SP APIs seem direct mappings of the c++ objects.

I am using C++ because I already have lots of graphic code on
c/c++(years of work) that I want to use in this project.

The SB API's are a C++ interface to lldb (that's how Xcode uses them, for example.) Those C++ API's are translated into
a Python interface (using the SWIG tool) for scripting purposes. But you should feel free to use the C++ version if you like C++.

I think Greg just suggested Python because it's an easy way to play around and figure out how they work.

Jim

You might want to look at test/api/multiple-debuggers/multi-process-driver.cpp which is an example C++ driver program which creates an lldb debug session (50 of them, actually), inserts breakpoints, runs to the breakpoints, backtraces and continues as a simple example in C++.

(the test itself is trying to hit race conditions with multiple debuggers running at the same time on separate threads.)

J

You can also have a look at CodeLite’s LLDB debugger plugin implementation (also, pure C++)
More specifically, this file: https://github.com/eranif/codelite/blob/master/LLDBDebugger/codelite-lldb/CodeLiteLLDBApp.cpp which wraps SB API (it converts JSON format commands arriving from CodeLite into SB API calls and send back the replies)

Eran

Thank you everybody.

I will be looking to all the suggestions. They are invaluable.

@Jason: The multiple debugging sessions is a great example when you
need to know what is the minimum lldb needs to run when you start from
scratch, 287lines of code!!