Ghidra: Dependency based redecompilation

[sad-dev]

Is your feature request related to a problem? Please describe.

Any change to the state of the database causes a flushing of the decompilation cache. This is inefficient and a major pain point on large binaries and/or large functions.

Related issues are:
https://github.com/NationalSecurityAgency/ghidra/issues/1883
https://github.com/NationalSecurityAgency/ghidra/issues/1871

Describe the solution you'd like
Certain changes should instead lead to a re-decompilation (ideally, pushed to background threads, but removing them from the cache is also fine) of only some functions in the cache which depend on the changed values. The obvious candidates are:

a.) Local variables and comments -> should only affect the current function. As mentioned in https://github.com/NationalSecurityAgency/ghidra/issues/1871, directly modifying the decompile tree followed by rebuilding the XML is theoretically possible, although as an initial version I would not mind just re-decompiling the current function.

b.) Changes in the function prototype or parameter renames should change the current function and mark all decompiled callers of the function for redecompilation

c.) Mapping which functions have decompiled output dependent on a type/structure definition is probably a stretch goal, but could be possible (similar to the find use of type/field feature already in ghidra).

Describe alternatives you've considered
I have resorted to using reflection from scripts to directly interact with the decompiler cache while performing the changes outlined in (a) and (b).

[astrelsky]

I would like to add that any change to the state of one program's database causes the decompiler cache to be flushed for ALL open programs. This a royal pain when manually comparing programs.

[gtackett]

I'm seriously considering 😄 creating a dozen or so extra github logins, just so that I could give this a few more thumbs up.