Dependent data type archives not properly syncing

[Schala]

Describe the bug When parsing a new data type archive from C headers which relies on data types already in another, opened archive, the result is often the resulting archive having a mix of type associations with that other archive and straight up copying various structs, enums, functions, etc., without any association. This results in having to manually purge duplicate defines and anonymous enums, and overwriting other duplicates with associations, which can be tedious.

To Reproduce Steps to reproduce the behavior:

1. Have an existing data type archive (msl80.gdt attached for this case) opened
2. Parse C headers whose contents depend on types in the existing GDT
3. When examining the resulting GDT (opengl12), the bug described above will be evident

Expected behavior All of the dependencies should be associated in the new archive (opengl12) with the existing, associated archive (msl80)

Screenshots From msl80:

From opengl12:

Attachments Headers.zip msl80.zip opengl12.zip (bugged result) opengl.zip (the parser profile I made for it)

If applicable, please attach any files that caused problems or log files generated by the software.

Environment (please complete the following information):

• OS: Windows 11
• Java Version: 13.2
• Ghidra Version: 10.1.5
• Ghidra Origin: official GitHub distro

[ghidra1]

This is likely caused by the CParser's use of DataType.copy instead of DataType.clone and should be easily resolved.

[Schala]

Also somewhat related. Apologies if I need to make this a separate issue but with generated GDTs, but is there a way to disable packing types by default?

[ghidra1]

is there a way to disable packing types by default?

@Schala , I believe packing is disabled by default for structures when instantiated. Although, the C-parser always enables packing for ones it produces (e.g., those we provide in data type archives) which is the correct thing to do when complete structure definition and its referenced types are known. For the C-parser this is the only way structure components will be assigned the correct offset. Disabled packing is only desirable when component offset are known and a complete definition is unknown (including sub-components such as incomplete unions).