Handle `FORWARD REF` leaves with no `UDT`

[disinvite]

We handle forward references for LF_STRUCTURE or LF_CLASS leaves by checking if the field list type is 0x0000. We don't parse the FORWARD REF attribute at all. If not equal to the leaf id, the UDT value tells what other leaf is referenced. This typically looks like:

0x2e94 : Length = 38, Leaf = 0x1504 LF_CLASS
	# members = 0,  field list type 0x0000, FORWARD REF, 
	Derivation list type 0x0000, VT shape type 0x0000
	Size = 0, class name = MxStreamProvider, UDT(0x0000b203)

However, some forward refs have no UDT at all:

0x2562 : Length = 30, Leaf = 0x1505 LF_STRUCTURE
        # members = 0,  field list type 0x0000, FORWARD REF,
        Derivation list type 0x0000, VT shape type 0x0000
        Size = 0, class name = HWND__

We have somehow avoided this problem up until now. It must be that these types are not referenced anywhere that we have been looking in either reccmp or datacmp.

[jonschz]

There actually is some logic for that specific case in the Ghidra import. Doesn't change the fact that we could have better handling in asmdiff.

[jonschz]

Could you elaborate on the problems that result from this? The specific case of HWND__ is an opaque type which should only ever appear in the form of a pointer (so effectively a void *, but with better type checking)

[disinvite]

Could you elaborate on the problems that result from this? The specific case of HWND__ is an opaque type which should only ever appear in the form of a pointer (so effectively a void *, but with better type checking)

I think this was just calling attention to a potential problem: if we tried to use any of the types that have no forward ref link (e.g. in datacmp, when generating array offset entities) we would throw a CvdumpIntegrityError.

These could be vestigial types: not used by any function, variable, arglist, etc. I'd have to go back and look at some PDBs to confirm.

[jonschz]

In the specific case of HWND__, we should never be able to get our hands on an instance in our code (unlike HWND__ *) since we don't have access to the struct layout anywhere in code. I believe (though I can't prove it) that whenever we are able to dereference a type, it will be contained in the PDB.

Question remains: Are there any other cases of missing forward refs that are not opaque types?

[disinvite]

The HWND__ comes from:

// FUNCTION: LEGO1 0x100b0b00
// FUNCTION: BETA10 0x10130b6b
MxOmniCreateParam::MxOmniCreateParam(
	const char* p_mediaPath,
	struct HWND__* p_windowHandle,
	MxVideoParam& p_vparam,
	MxOmniCreateFlags p_flags
)
{
	this->m_mediaPath = p_mediaPath;
	this->m_windowHandle = (HWND) p_windowHandle;
	this->m_videoParam = p_vparam;
	this->m_createFlags = p_flags;
}

There is also:

0x6ca2 : Length = 26, Leaf = 0x1505 LF_STRUCTURE
    # members = 0,  field list type 0x0000, FORWARD REF, 
    Derivation list type 0x0000, VT shape type 0x0000
    Size = 0, class name = _PSP

That must be from CRT code because you would never reference that in your own program.

I'm pretty sure this started with a PDB other than LEGO1, though. I'll look again.

[disinvite]

I couldn't find an example in any of the PDBs I was working on when this opened. So it is just HWND__. If that's not enough cause for us to do anything beyond what's already there in the Ghidra scripts, we can close this.

[jonschz]

I agree. Let's reopen this in case we encounter a situation that is fundamentally different from the HWND case.