I want to implement some additional interfaces on top of LLDB using python and I was hoping someone might be able to tell me how feasible it would be to do just using LLDB's embedded python interpreter.
I would like to run a regular LLDB session in one terminal and display register contents, disassembly and stack contents in other windows to somewhat mimic the displays of debuggers like Immunity or OllyDbg on Windows. I'd prefer to not have to implement a full new front end for LLDB as this is just intended to be complementary to the standard console interface to LLDB. I think I would need to be able to register handlers to be called on breakpoints (this looks quite easy from the documentation), but also handlers to be called after stepping over an instruction (to update the selected line in the disassembly, update register contents display, etc).
Does this sound like something that could be easily implemented using the embedded python scripting? I have had a look at the documentation but I can't see anything that help with this. I'm open to other suggestions
I didn't really explain that particularly well - I figured I would have external python scripts that draw the UI for other windows using ncurses and connect to some comms channel opened by whatever is running within LLDB's python interpreter. These external scripts would be consumers of data pushed out by that internal script and render that data (disassembly around current EIP/RIP, stack data, etc). Really I should just implement a full new front end but I will never get around to it and just want a cheap way out.
I may be missing your point here, but I guess the easiest way would be for you to create an LLDB SBDebugger instance, and use its SBCommandInterpreter to send commands and read replies. Then, you can parse the command output for each thing you send, and use the parsed information to generate your visuals.
If you are particularly adventurous you could even create a Python class with method calls like SetBreakpoint, Step, … and have these methods send the right commands and return you correctly parsed output.
Of course, if anything in the way LLDB displays data changes, your parser would have to change along with it. But, for a cheap way out, this one seems pretty reasonable.
✆ 408.974.5572 | egranata@.com
After looking at the API a bit more closely I guess that’s a decent option since most of the console functionality is handled in SDCommandInterpreter. I was just hoping to not need to put anything in front of the LLDB console or replace it - but replacing it doesn’t seem as annoying as I thought it would. I’ll give that a try.