Ghidra: FunctionManagerChangeListener

[Megacrafter127]

Is your feature request related to a problem? Please describe.
I wanted to create a plugin that would automatically create and update FunctionDefinitionDataTypes for a large number of functions. (as manually updating those datatypes whenever the signature of the relevant function changes is a hassle)
This requires detecting when the signature of a function has been updated.
However, in the API documentation I cannot find any way to do.
I did find a way to listen for changes to data types, but not for functions.

Describe the solution you'd like
Since DataTypeManagerChangerListener solves the above problem for data types, I suggest adding a FunctionManagerChangeListener, that solves the same problem for functions.

Describe alternatives you've considered
While one could instead periodically iterate over all relevant functions and test if they have been altered since the last test, but I don't think that should be the intended way.

Additional context
-

[astrelsky]

I also have a need for this for _vptrs.

I haven't gotten to the point in looking to implement it yet though. It may already be possible through domain object change listener or the program change one. I'm going off the top of my head though.

To be honest it would be nice to have a FunctionDefinitionDataType which changes automatically as long as it is contained within a ProgramDataTypeManager.

Edit: You actually may be able to pull this off. See DomainObjectListener, DomainObjectChangeRecord and ChangeManager.DOCR_FUNCTION_CHANGED

[dragonmacher]

@astrelsky is correct. We use the program's listener mechanism to allow plugins to monitor changes to the program data. Your plugin will get notified as programs are opened and closed; you can add and remove your listener when this happens.

See FunctionWindowPlugin.domainObjectChanged() as an example of a plugin that monitors function-related changes.

[astrelsky]

@astrelsky is correct. We use the program's listener mechanism to allow plugins to monitor changes to the program data. Your plugin will get notified as programs are opened and closed; you can add and remove your listener when this happens.

See FunctionWindowPlugin.domainObjectChanged() as an example of a plugin that monitors function-related changes.

I still think it would be a good idea to have a listener for each specific manager. I can see things being bottle necked since every listener would be called for every individual change. If I only want to listen for a function change for example, my listener would be invoked for every change even though it would only apply to function changes.

[dragonmacher]

@astrelsky This is a valid point. We have had discussions about changing how listeners subscribe to events in order to prevent excess client event processing. What we have now does not scale well and is quite a bit clunky to program.

[astrelsky]

@astrelsky This is a valid point. We have had discussions about changing how listeners subscribe to events in order to prevent excess client event processing. What we have now does not scale well and is quite a bit clunky to program.

What about adding addListener and removeListener to the ManagerDB interface? A Listener interface could be used as a Tag Interface for the methods. That would at least split out the load among a program's domain object listeners.

Also this would work well for most of them as it could be put in a switch statement since the ChangeManager fields are compile-time constants even if they aren't changed to an enum.

[dragonmacher]

What about adding addListener and removeListener to the ManagerDB interface? A Listener interface could be used as a Tag Interface for the methods. That would at least split out the load among a program's domain object listeners.

This starts to become an implementation issue. The managers are hidden from the plugins. Some of them may be exposed via a service interface, but they are not intended to be public. I think the idea of being able to subscribe to events of interest is the right path though, however we accomplish that. Ultimately, we may need both ways of listening. Some clients choose to perform rather elaborate updates, depending upon how many events they get, and in what order. But, for simple plugins that wish only to know of a small set of events, it makes sense they should be able to implement a simple callback.

There is a bit more to this under the hood as well. Implementation-wise, it is easy for a naive client to process every event. When we have thousands of events go out, Ghidra can bog down with that style of event handling. My hope is that a better event system would not only be simpler to program for basic plugins, but would also allow us to coalesce events, allowing us to turn thousands of events into a small handful.

As a tip to plugin writers that may run into this issue, we currently will have the client buffer event responses, usually via our SwingUpdateManager or one of our multi-threaded widgets, such as the GTable or GTree. (The tree and table have internal logic to handle buffering.) For examples of this, look at the various UI-based plugins and how they implement domainObjectChanged() (just don't look at a bad example :wink: ).