ghidra icon indicating copy to clipboard operation
ghidra copied to clipboard

Data Type Manager: drag-and-drop should respect selected DataTypeConflictHandler

Open MichaelEbert opened this issue 3 years ago • 3 comments

Is your feature request related to a problem? Please describe. When I drag and drop types from a file archive to a program archive, types from the file archive are renamed .conflict, no matter what the data type conflict handler I have set is.

Example: program.exe contains a definition for struct s1 { char a}; library.gdt contains a definition for struct s1 {char* a}; conflict handler is set to "Replace Existing Data Type" when s1 is dragged and dropped from library.gdt to program.exe in the data type manager, it creates the structure s1.conflict.

Describe the solution you'd like if the data type conflict handler is set to "replace existing data type", it should replace existing data types with the same name. If the data type conflict handler is set to "use existing data type", it should use the existing data type and ignore the new data type. Current behavior will be preserved with the "Rename new or moved data type" handler, which is the default.

Describe alternatives you've considered Alternately, I'm Using It Wrong and documentation should be updated on how to use the data type manager correctly.

Additional context see CreateStructure in ghidra/Ghidra/Framework/SoftwareModeling/src/main/java/ghidra/program/database/data/DataTypeManagerDB.java

MichaelEbert avatar Oct 02 '22 11:10 MichaelEbert

While we need to investigate the resolve logic for types pulled from archives, a work around would be to drag the type from the archive onto the type it is replacing. Although, that will not handle any sub-types which get auto-resolved in the process.

ghidra1 avatar Oct 06 '22 18:10 ghidra1

I believe this relates to an open issue previously identified internally (GP-1307):
DataTypeManagerDB does not currently perform proper conflict handling when the type being resolved has a source (resolveDataTypeWithSource) when considering a potential conflict with a local type (no-source).

ghidra1 avatar Oct 21 '22 14:10 ghidra1

Yes that sounds correct.

MichaelEbert avatar Oct 21 '22 19:10 MichaelEbert