Prepare for LLDB plugin: Move Disassemble/Registers toolview into common
ClosedPublic

Authored by qi437103 on Jul 18 2016, 4:19 AM.

Details

Summary
  • 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.

Test Plan

gdb unit tests

Diff Detail

Repository
R32 KDevelop
Lint
Automatic diff as part of commit; lint not applicable.
Unit
Automatic diff as part of commit; unit tests not applicable.
qi437103 updated this revision to Diff 5249.Jul 18 2016, 4:19 AM
qi437103 retitled this revision from to Prepare for LLDB plugin: Move Disassemble/Registers toolview into common.
qi437103 updated this object.
qi437103 edited the test plan for this revision. (Show Details)
qi437103 added a reviewer: apol.
Restricted Application added a subscriber: kdevelop-devel. · View Herald TranscriptJul 18 2016, 4:19 AM
apol edited edge metadata.Jul 18 2016, 1:12 PM

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.

apol added a comment.Jul 19 2016, 9:00 AM

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.

You can test common, that's what I meant.

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.

apol accepted this revision.Jul 20 2016, 8:14 AM
apol edited edge metadata.

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.

This revision is now accepted and ready to land.Jul 20 2016, 8:14 AM
This revision was automatically updated to reflect the committed changes.