Ghidra1

Change has been added which allows both a program architecture to be assigned to an archive as well as assigning calling conventions to `FunctionDefinitions` based upon string name instead of...

This may be fixed by commit 02b0dfe which will soon be pushed.

Sorry, apparently it is not fixed by this latest change.

The disassembly markup does not consider the access size which does not align with actual component sizes. It simply identifies the location where the write occurs.

The decompiler will not show as structure member access since the accesses do not match-up properly with components. The writes are compiler generated for simplified/rapid clearing of structure data.

Can this issue be closed?

> Can this issue be closed? Sorry, not sure why i asked about closing. We have an open internal ticket to look into/resolve.

I assume these are contained with different Categories. Otherwise, Ghidra would have named one of them with a `.conflict ` suffix.

If your situation is simialr to my test, you start with three types: 1. Function Definition (internal.h/functions/_PVFV) 2. A pointer to the Function Definition (internal.h/functions/_PVFV *), and 3. A typedef...

The issue stems from a bug in the datatype resolution logic that did not properly handle the duplicate name between typedef and associated struct. Fix is in the works.