I’m referencing the below post where i talked about the possibilities of developing a plugin host with debugging capabilities.
Ideas that have been thrown around include features such as inspecting a graphical plot of the contents of a vector or array, quick setting of conditional break points to be hit after a specific number of process block runs, visualisations of pre and post processed signals (spec displays, waveform etc.) and test signal generators etc.
I’ll be looking at this in my spare time (when I can find it alongside all the academics and work) but am still really interested in having a go. Hoping this might become one of those open source contributions I keep meaning to get on for the sake of the old portfolio
What would people’s thoughts be on this being lldb only for the first iteration / time around ?
LLDB has a reasonably well maintained and mature C++ API whilst GDB’s C api is looking like it may be a bit of an arcane nightmare.
The alternatives are to use each of the debuggers Machine Interface commands. See:
In which case some functionality could be duplicated but the MI’s don’t appear to have a complete set of commands implemented at this point.
The other option of course is looking at python…I’ve got little to 0 python experience though. But it’s all a learning curve. Boost.Py as a start I guess.
Does anyone have any thoughts on this or a suggestion for what approach they think would be best?
(I’m attempting to workout whether its feasible to load the plug/dll and debug all within the one host - I’m hoping this should be possible with lldb running/spawned off in a separate process)
I’ve looked at Xspray for some inspiration which uses LLDB’s C++ API but solid GDB support would be good to have in a project like this…
(Bump in case anyone has thoughts)