- Move registers into common
- Move DisassembleWidget into common
- Correct debug log output category in common
Both RegisterController and DisassembleWidget now accepts MIDebuggerPlugin and MIDebugSession,
so LLDB plugin can reuse the same toolview.
apol |
KDevelop |
Both RegisterController and DisassembleWidget now accepts MIDebuggerPlugin and MIDebugSession,
so LLDB plugin can reuse the same toolview.
gdb unit tests
Automatic diff as part of commit; lint not applicable. |
Automatic diff as part of commit; unit tests not applicable. |
It looks like it would make sense to at least add tests for some of this. Not necessarily the UI but we're enforcing MI to be the same on LLDB and GDB.
Yes, I think we should have tests for LLDB. But is it necessary to have the same tests for GDB? After all GDB itself is the specification...
I plan to add hook in LldbCommand to fix a few commands (one or two) that doesn't work, and add related tests. It's on peifeng/lldb-plugin branch so I want to wait until this patch get accepted to master.
IMHO, common is just a library that can be used by either GDB or LLDB, and with default settings working out-of-box for GDB. If GDB or LLDB plugin wants different behavior, it could subclass and change it. And it's the GDB or LLDB plugin's responsibility to test whether common works as expected.
Also, technically, you can't just simply test common without pulling in GDB or LLDB specific code, as common itself isn't a complete plugin and isn't associated with any debugger. While it's possible to test it by adding extra mock objects and use either/both GDB and LLDB as backend, I feel it's simpler to just test it in either GDB or LLDB code.
Also, technically, you can't just simply test common without pulling in GDB or LLDB specific code, as common itself isn't a complete plugin and isn't associated with any debugger. While it's possible to test it by adding extra mock objects and use either/both GDB and LLDB as backend, I feel it's simpler to just test it in either GDB or LLDB code.
Oh well. You can definitely test libraries. Another thing is if it's really hard to test nowadays because it's a bit of a monster at the moment, because it's essentially 2 plugins in one.
It's ok then, just test both plugins properly if it's what we can do.