gdbgui
gdbgui copied to clipboard
cs01
Add support for LLDB
I mostly use lldb on mac and gdb on linux. Could this be made to work with lldb as well?
The mapping in commands from gdb to lldb is 1:1, the commands are often just named slightly differently. I'd like to use something that gives me a smooth experience with both.
Absolutely, I'll take a look at lldb and see how hard it would accommodate it.
gdbgui relies on gdb's machine interface (mi) output. lldb does not have this as a built in option, but it looks like someone wrote an intermediate application to provide mi-like output: https://www.codeplay.com/portal/lldb-mi-driver---part-1-introduction. Looks like it won't be as easy as I was hoping, but still seems possible to do.
I think you just need to call lldb-mi instead of lldb. The lldb-mi driver is part of LLVM and is built by default when you build lldb.
Thanks, lldb-mi is what I was looking for. Documentation and implementation are a little sparse for lldb-mi. I did make a lot of progress, but there are some commands that don't seem to have a gdb-mi equivalent.
You can try it out now with, for example, gdbgui/backend.py -g lldb-mi-3.8.
Where gdbgui works with lldb:
- Loading and running files
- Viewing Locals
- Viewing Expressions
- Console
- Registers
- Memory
Where gdbgui has issues or partial functionality with lldb:
- Breakpoints
- Threads/Stack rendering
- Disassembly
I marked all areas of the source code that have such issues with TODOLLDB.
Any help in these areas would be appreciated.
@cs01 IIUC lldb-mi should be 1:1 exactly compatible with gdb-mi, but the project is not that old, so maybe the features that you mention are just not implemented yet. I think that you could show your work on the llvm mailing list, and ask for help about the remaining lldb-mi commands that right now do not work. I see that you are using llvm 3.8, so maybe those issues are already fixed in 3.9 or 4.0. I'm sure the LLDB guys will be keen to help!
@gnzlbg I updated and tried with
>> lldb-mi-4.0 --version
Version: GNU gdb (GDB) 7.4
(This is a MI stub on top of LLDB and not GDB)
All rights reserved.
It seemed a little improved but certainly still not 1:1. The earliest version of gdb that gdbgui was tested with was 7.7.1, and it looks like this lldb-mi api is compatible with gdb 7.4. I'll try sending an email to the mailing list, thanks.
@gnzlbg I sent two emails to the mailing list and haven't heard anything back.
lldb-mi compatibility with gdb 7.12 mi2 interpreter
pinging: @codeplaysoftware , @zjturner , @abidh , they might be able to help.
Thanks @gnzlbg, @zjturner tried to get something going for me on the lldb-dev mailing list, but still no responses.
It looks like another path forward would be to use the LLDB Python Reference: http://lldb.llvm.org/python-reference.html.
Rather than extending lldb-mi to fully implement gdb-mi, the lldb Python interface may be useful. I would like to try to use some existing code that does this. Perhaps from the voltron project. Other recommendations for lldb/python script api's are welcome.
Once that's implemented, gdbgui can choose which controller to use depending on if the user wants to use gdb or lldb.
Might be worth it to hit up the LLVM IRC channel. They're very responsive in there.
@Qix- thanks. I might try that at some point. I think my best bet might be to look up gdb mi's 7.4 documentation and try to use that API, but I'll keep the IRC channel in mind too.
Unfortunately no, and it is not something that I plan to work on anytime soon. Are you interested in giving it a go? I could help you navigate gdbgui's codebase and understand the architecture.
In the long term I would like to use VSCode Debug Adapters so that the entire front end is provided data from a VSCode Debug Adapter. This will enable gdbgui to work with any language and become a generic browser based debugger. So gdb and LLDB would work, but so would Python debuggers, and any other language that had its debugger protocol translated to VSCode's Protocol. This would required updating pygdbmi, which shouldn't be so hard since its already structured, and making it work (or forking it to work) to work with LLDB.
https://github.com/vadimcn/vscode-lldb already exists for VSCode; maybe some of that code could be reused.
Making gdbgui work with VSCode adapters would IMO be a huge benefit for the programming world.
I came across this issue a while ago and this week I saw an interesting mail passing by on the llvm mailing list. Thought it might be interesting/relevant for you guys: http://lists.llvm.org/pipermail/llvm-dev/2018-August/125262.html
For anyone reading this who has lldb-mi installed, gdbgui does kinda work with it. It might be enough to get you want you want (and it's certainly easier than trying to get gdb installed and codesigned on a mac if you haven't already done that).
gdbgui -g <path to lldb-mi>
When you download clang binaries for Windows from here - https://releases.llvm.org/download.html
They already come with a compiled lldb - that works! Well, kinda, you need to downoad a python dll manually - https://stackoverflow.com/questions/61731940/lldb-windows-errors-with-clang-10/
Still, this is the only "native" way to have a C++ debugger on Windows. Would be sweet to be able to use it with gdbgui..
@gnzlbg I sent two emails to the mailing list and haven't heard anything back.
Having to contact them via some mailing list, that is so ancient and weird.. I can understand why you got dissuaded :/
Unfortunately no, and it is not something that I plan to work on anytime soon. Are you interested in giving it a go? I could help you navigate gdbgui's codebase and understand the architecture.
In the long term I would like to use VSCode Debug Adapters so that the entire front end is provided data from a VSCode Debug Adapter. This will enable gdbgui to work with any language and become a generic browser based debugger. So gdb and LLDB would work, but so would Python debuggers, and any other language that had its debugger protocol translated to VSCode's Protocol. This would required updating pygdbmi, which shouldn't be so hard since its already structured, and making it work (or forking it to work) to work with LLDB.
https://github.com/vadimcn/vscode-lldb already exists for VSCode; maybe some of that code could be reused.
Making gdbgui work with VSCode adapters would IMO be a huge benefit for the programming world.
Any advances on the Debug Adapter implementation? That thing would be a game changer for sure!
Unfortunately, no. I am the only maintainer of this tool, and I am only doing critical bug fixes as they arise. I’m not opposed to more people jumping in with pull requests though.