Ghidra: Ghidra unresponsive during DWARF import

[astrelsky]

Describe the bug
Importing DWARF information causes ghidra to become unresponsive.

To Reproduce
Steps to reproduce the behavior:

1. Import binary containing DWARF debug
2. Import DWARF information
3. Ghidra hangs until the import completes if at all

Expected behavior
Ghidra should be responsive during import and should import the information at an acceptable rate.

Screenshots
If applicable, add screenshots to help explain your problem.

Attachments
Unlinked arm binary
rpi-i2c.tar.gz

Environment (please complete the following information):

• OS: Microsoft Windows [Version 10.0.18363.657]
• Java Version: 13.0.2
• Ghidra Version: 9.2

Additional context
This appears to be a regression as it wasn't an issue until this week.

[astrelsky]

Another note is that it appears to take longer with the anonymous structure option enabled.

[dev747368]

eh, don't put too much effort into tracking this down. We're aware of some non-dwarf changes to the data type manager that destabilized everything and we're working on it. Thanks for the heads up about it effecting dwarf so strongly.

[astrelsky]

eh, don't put too much effort into tracking this down. We're aware of some non-dwarf changes to the data type manager that destabilized everything and we're working on it. Thanks for the heads up about it effecting dwarf so strongly.

Ah it is the dtm. I normally would have edited the comment in but didn't because it had already been seen and labeled.

Also, I appreciate the heads up to not put much effort into tracking it down because I definitely would have if given the time.

[astrelsky]

@dev747368 I just stumbled across something that may be of interest. I noticed that there is a MASSIVE performance difference with DataTypeManager.resolve when using the KEEP/REPLACE handlers. It may be that components of composite/function datatypes are being recursively replaced unnecessarily. It could be as simple as adding a check somewhere to see if the type is equivalent to what currently exists before replacing it.

This was noticed while populating a DataTypeManager with a script. I'm able to get away with keeping them because the manager was initially empty.

[ghizard]

@astrelsky I've run into performance issues in these conflict handler for PDB. @ghidra1 was looking at some possible improvements in this area that I think will help with PDB (and DWARF), and I believe @dev747368 might have had some changes in the works as well for DWARF. Not promising anything, and not sure if it would address this issue here. I'm mainly noting that we are aware of performance issues and hope for improvement.

[astrelsky]

@ghizard If you'd like I can put together a script and attach it along with a gdt built from libstdc++ that would make profiling the handlers a breeze.