Enabling DebuggerListingPlugin and CodeBrowserPlugin at the same time

[msm-cert]

Hi!

Recently I'm working on improving my Ghidra configuration (and even releasing some plugins). But since I don't fully get the concept of "tools", I prefer to have all the options available in my main window.

Hence my question: I have a shortcut to open listing window configured. If both DebuggerListingPlugin and CodeBrowserPlugin are enabled, then that shortcut conflicts. This is a single action, so i can't configure different keybindings:

Keybindings page confirms that only a single action (from two plugins) is mapped to this keybinding:

But when I press that combination:

Is there a standard workaround for this? I like my current configuration (for example, I can do quick emulation of an interesting fragment without switching tools), but a lack of listing keybinding is an issue for me.

(I guess I can make my own Ghidra module that exposes this action with a different keybinding, but that feels like an overkill for what should be a simple configuration change).

[dragonmacher]

The issue, as you pointed out, is that the Debugger Listing and the Code Browser Listing are not both in the same tool in our configuration. We make both use the same key binding so that if the user changes it for one tool, it will work in the other tool.

A tool is simply a collection of plugins. Users can create their own tools and add plugins they like to them. This allows users to have different tools for different type of tasks, if they wish. I'd venture a guess that almost no users create custom tools. We ship pre-built tools for major features, such as the Debugger and Version Tracking.

As I mentioned, we have written the Debugger Listing and the Code Browser Listing share the same key binding out of convenience for the user. There is no easy way for you to change this behavior. If you really wish to use both Listings in one tool, then you have to accept this current limitation (choosing the desired Listing in the dialog you have shown above each time you press the key binding).

[msm-cert]

Thanks for your response!

A tool is simply a collection of plugins. Users can create their own tools and add plugins they like to them. This allows users to have different tools for different type of tasks, if they wish. I'd venture a guess that almost no users create custom tools

I understand this much. Actually I created my own "supertool" with most plugins enabled, but clearly I'm doing things wrong :).

As I mentioned, we have written the Debugger Listing and the Code Browser Listing share the same key binding out of convenience for the user.

Does it mean that if I have Ctrl+Back Quite configured for a Code Browser "Listing", it should automatically work in Debugger tool? If yes, I'll debug my installation a bit - because it doesn't happen for me: keybindings configured in tools are independent.

If you really wish to use both Listings in one tool, then you have to accept this current limitation

My real goal is to have a quick access to debugger/emulator when browsing code. Since it looks like I'm going against the "spirit" of the program, I probably approached it the wrong way, or maybe my idea is just not good fit for Ghidra.

I explained my reasoning in d-millar answer, but I just wanted to say that technically there is a hacky workaround - I can create a Ghidra plugin, that will expose "My Listing" keybinding (implemented by simply forwarding it to another action), bind my shortcut to it, and unbind "Listing". But I'd rather learn what I'm doing wrong.

[d-millar]

@msm-cert Can I ask why you have both plugins in the tool? There's very little difference in the functionality. I'm wondering what the inclusion of the Code Browser in the tool is buying you.

[msm-cert]

Thanks for your response!

@msm-cert Can I ask why you have both plugins in the tool? There's very little difference in the functionality. I'm wondering what the inclusion of the Code Browser in the tool is buying you.

I'll explain from my point of view. My main tool is and always was the Code Browser. I'm trying to integrate Ghidra's debugger/emulator into my workflow, but for now I'm mostly using debugger/emulator to quickly emulate pieces of code. Initially when I wanted to do this, I saved the program, turned off the code browser, opened a debugger or emulator (with my normal keybindings missing), did what I wanted (for example emulated a function), saved the program, closed debugger/emulator, opened a code browser again. That's a lot of steps for a quick check.

So I figured, why not enable debugger and emulator in my main tool. Which works great for me, well except that keybinding issue.

Since you both seem to consider my idea convoluted, I should probably take a step back. What should I do if I mainly want to browse code, but I want to also be able to emulate/run pieces of code without switching tools? Just use debugger as my main tool? Or should I just (try to) get used to frequent tool switching?

[dragonmacher]

but I just wanted to say that technically there is a hacky workaround - I can create a Ghidra plugin, that will expose "My Listing" keybinding (implemented by simply forwarding it to another action), bind my shortcut to it, and unbind "Listing". But I'd rather learn what I'm doing wrong.

You certainly can create custom actions yourself via a plugin. You can create an action to open the Debugger Listing and an action to open the Code Browser Listing. With two separate actions, you can make the keybindings be whatever you like. If this is what you were describing, then this should work.

Since you both seem to consider my idea convoluted,

'Convoluted' is a harsh word. We certainly did not intend for users to make a super tool like this, but the desire makes sense to me, as this is how some other non-Ghidra apps work. If you make a super tool, there will be workflow issues like you mention here, since we have not tested and fixed issues like that. I will leave it up to @d-millar to answer as to what the best workflow should be for your situation.

[msm-cert]

I'm a Ghidra user for some years now, but indeed I'm more used to having everything accessible in one window (or tool in this case). Thanks for explaining.

[d-millar]

I get where you're coming from on this, but you should probably think of the Debugger Listing as a Code Browser with some plumbing for debugging / emulation. Given this, there are a couple of ways for you to proceed. One would be to default to using either the Debugger Tool or the Emulator Tool as your "Code Browser". That said, either of those might be a little cluttered for your tastes. If it were me, I would make a copy of the Emulator Tool and configure it by eliminating anything I thought was extraneous to my workflow. Alternatively, you could make a copy of the CodeBrowser Tool and add the Debugger/Emulator features you wanted (or just use your super-tool) and remove the CodeBrowser plugin. I think the former is more likely to work out-of-the-box, but either should be do-able. If either of those don't work, I'd actually like to know. There are probably relatively simple things we can do to address that.

[msm-cert]

Yeah that makes sense. Debugger/emulator being cluttered is not a problem, I already moved some windows ("dockable GUI components") around in my tool.

I think I understand now where my problem was, and I understand better what "Debugger Listing" is. I'll try with the approach you suggested. If I encounter any problems I'll let you know (but that sounds like a solid plan that should work).

I hope that's OK for me to close the discussion, as i think everything's clear now. Thanks again.