Handle additional information in newer MSVC versions correctly

[jonschz]

Running reccmp-reccmp I get the following:

AssertionError: Unhandled in union:     # members = 2,  field list type 0x22e2, SEALED, Size = 4        ,class name = <unnamed-tag>, unique name = .?AT<unnamed-tag>@@

If I look in the console output, the first error I get is:

[ERROR] Unmatched line in class:        Size = (LF_ULONG) 320996, class name = ViewportRenderState, unique name = .?AVViewportRenderState@@, UDT(0x00001056

I am running reccmp-reccmp on: the original binary, the recompiled binary (Release build), the Release build pdb file.

What should I look into to get this issue resolved?

I annotated my class function like this:
The game uses a single static instance of this class, so my recompilation does too.

class ViewportRenderState : ViewportRenderStateStruct {
    public:

    //FUNCTION: MYEXE 0x401000
    BOOL xyAreValid( uint x, uint y) {
        ....
    }
}

Originally posted by @gynt in #82

[jonschz]

This looks like additional information in the debug symbols that the code does not handle yet. Please run cvdump on your pdb file and upload it here (probably something like .\reccmp\bin\cvdump.exe myfile.pdb > dump.txt).

[gynt]

Hi! Here is a simple class implementation in latest MSVC using cmake: https://github.com/gynt/reccmp-tests
dump.txt is 30 MB (: https://github.com/gynt/reccmp-tests/blob/ef062d76c33efc1564bd7d881bf4b50c0bac5bf7/dump.txt

[jonschz]

@gynt Feel free to try the latest version on master and see whether things have improved for you. As mentioned on #86, datacmp is likely still broken.

[gynt]

Works, using --verbose I now get a neat display of everything that doesn't match up (:

There is a bunch of [ERROR] Unhandled symbol type: ... but it doesn't exit the program early so I am not complaining at this point!

[jonschz]

Some preliminary insights from poking around in the dump @gynt provided:

• The unknown types we have at the moment are:
  • ???(007C)
  • ???(047C)
  • ???(0x009b) (possibly not a type)

Hypothesis for 007C

0x2020 : Length = 506, Leaf = 0x1203 LF_FIELDLIST
[...]
	list[2] = LF_NESTTYPE, type = ???(007C), extern_type
[...]

0x2021 : Length = 98, Leaf = 0x1504 LF_CLASS
	# members = 23,  field list type 0x2020, CONSTRUCTOR, CONTAINS NESTED, 
	Derivation list type 0x0000, VT shape type 0x1204
	Size = 8, class name = std::codecvt<char16_t,char8_t,_Mbstatet>, [...]

together with https://en.cppreference.com/w/cpp/locale/codecvt suggests that ???(007C) = char8_t.

Hypothesis for 047C

0x11da : Length = 26, Leaf = 0x1009 LF_MFUNCTION
	Return type = ???(047C), [...]

0x11db : Length = 18, Leaf = 0x1206 LF_METHODLIST
	list[0] = public, STATIC, 0x11D8, 
	list[1] = public, STATIC, 0x11DA, 

0x11e4 : Length = 446, Leaf = 0x1203 LF_FIELDLIST
	list[1] = LF_NESTTYPE, type = ???(007C), value_type
	list[2] = LF_NESTTYPE, type = ???(047C), pointer
[...]
	list[12] = LF_METHOD, count = 2, list = 0x11DB, name = 'allocate'
[...]

0x11e5 : Length = 138, Leaf = 0x1505 LF_STRUCTURE
	# members = 17,  field list type 0x11e4, CONTAINS NESTED, 
	Derivation list type 0x0000, VT shape type 0x0000
	Size = 1, class name = std::_Default_allocator_traits<std::allocator<char8_t> >, [...]

Source code excerpt from https://stackoverflow.com/q/51215399:

template<class _Alloc>
struct _Default_allocator_traits
{   // traits for std::allocator
using allocator_type = _Alloc;
using value_type = typename _Alloc::value_type;

using pointer = value_type *;
using const_pointer = const value_type *;
// ...
}

suggests that ???(007C) = value_type = char8_t and ???(047C) = pointer = char8_t *. This also matches the return type of allocate().