a GUI frontend of LLDB

Hi,

I’m working on a GUI frontend of LLDB which is based on Python 2.7 and Qt 4:
https://github.com/c0deforfun/LLL

Screenshot of current status:
https://raw.githubusercontent.com/c0deforfun/LLL/master/docs/screenshot.png

There’re still a lot of works to do. It would be really helpful if someone could join the project.
Any suggestions or comments will be appreciated too!

Btw, I have a question:
when users set a breakpoint at some line, SBBreakpointLocation may return a different line No. My current workaround is grep it from SBBreakpoint.GetDescription()

Thanks,
C0deforfun

Sorry but I think a GUI built with anything other than C or C++ is a waste of time. Especially a debugger only GUI. I have some personal experience.

There are a couple decent full IDEs available.
It would be more appropriate to integrate LLDB into one of these.

CodeBlocks, CodeLite, or Eclipse CDT are the better ones.
Though I am not picularly fond of Eclipse or any Java based GUIs either it would be preferable to any dynamic language. I prefer languages with strong type checking to eliminate many bugs at compile time.

You may be able to integrate with the express editions of visual studio. I hope I haven’t just committed heresy on this list. :slight_smile:

Thanks,
J.R. Heisey

Sorry but I think a GUI built with anything other than C or C++ is a waste
of time. Especially a debugger only GUI. I have some personal experience.

There are a couple decent full IDEs available.
It would be more appropriate to integrate LLDB into one of these.

CodeBlocks, CodeLite

​FYI: CodeLite already have a LLDB plugin​

​(for Linux, OSX. For Windows, we only enable Remote debugging using our
proxy "codelite-lldb")​
​http://codelite.org/LiteEditor/DebugWithLLDB

, or Eclipse CDT are the better ones.

There is a partial lldb-mi support in NetBeans. You can use it on any Java-friendly platform.

Hopefully this list can be more civil than this.

- Bruce

Hi,

I'm working on a GUI frontend of LLDB which is based on Python 2.7 and Qt 4:
https://github.com/c0deforfun/LLL

Screenshot of current status:
https://raw.githubusercontent.com/c0deforfun/LLL/master/docs/screenshot.png

There're still a lot of works to do. It would be really helpful if someone could join the project.
Any suggestions or comments will be appreciated too!

Btw, I have a question:
when users set a breakpoint at some line, SBBreakpointLocation may return a different line No. My current workaround is grep it from SBBreakpoint.GetDescription()

This can happen when a breakpoint is set on a line that doesn't generate any code. Then the breakpoint will be moved to the nearest line afterwards that does generate code. For instance, setting a breakpoint on some code that is in a:

#if 0

#endif

block will cause it to be moved to the line after the #if 0'ed code. If it is happening for you in code that looks like it is actually getting executed however, then that's a bug (most likely a bug in the line table information, but it could be an lldb bug as well.)

You don't need to grep GetDescription for the line number, however. Just get the Location's SBAddress, (SBBreakpointLocation::GetAddress(), then get the SBSymbolContext from the address (SBAddress::GetSymbolContext(lldb.eSymbolContextEverything)). The symbol context has a SBLineEntry (SBSymbolContext::GetLineEntry()) and that has the file spec & line number.

Jim

Thanks for the comment. I agree strong typed language can eliminate a lot of bugs at compile time but for small project like this, it should be OK though.
And I’m not interested in integrating into IDE. Currently, I work on LLVM dev and my dev environment is gvim (with some plugins) + cmake/ninja + gdb/DDD. I tried CDT but it uses too much resources.
Beside, I don’t like the concept of “project” in IDE, which is an overhead to me.
Basically, my goal is a counterpart of DDD.

Anyway, thanks for your opinion,
C0deforfun

Hi Jim,

Cool! Thanks a lot!
Your analysis is correct.
Let me try you solution!

Thanks

Hi Jim,

Unfortunately, it still has the issue:

For example, for https://github.com/c0deforfun/LLL/blob/master/sample/main/main.c:
I set bp at line 37 :
i = foo(argc,2);
(foo is in another CU, so won’t be inlined)
However, GetAddress().GetSymbolContext(lldb.eSymbolContextEverything).GetLineEntry()) shows it’s at line 38.

commandline has the same issue:

(lldb) b main.c:37
Breakpoint 1: where = test`main + 192 at main.c:38, address = 0x0000000000400677

In commandline script:

ss=lldb.SBStream() >>> lldb.target.FindBreakpointByID(1).GetDescription(ss) >>> print(ss.GetData()) SBBreakpoint: id = 1, file = ‘main.c’, line = 37, locations = 1

print(lldb.target.FindBreakpointByID(1).GetLocationAtIndex(0).GetAddress().GetSymbolContext(lldb.eSymbolContextEverything).GetLineEntry()) /home/media/Shared/LLL/sample/main/main.c:38

I expect a consistent user experience: wherever users clicks a line for bp, a dot will been shown at that line.

Thanks

If I build your little main.c (and some foo.c that has a trivial function foo in it) with a fairly recent clang at -O0, then the breakpoint on line 37 gets correctly set on line 37. Actually the same thing happens at -O3 with a fairly recent clang, clang has been getting better recently at tracking source lines through the optimizer, though this is not always easy to do.

You can check what the line table actually says in lldb with the command:

(lldb) image dump line-table main.c

and see if that makes sense with what you are seeing. If not, that is most likely a bug in the compiler's line table generation.

Anyway, if you want to pursue this further, you should file a bug with the complete set of files you use, and also what compiler you are using to build them and how you invoke the compiler.

Jim