Avoid object layout mismatch between coreclr and mscordaccore by comparing them during the build.

[cshung]

No description provided.

[sdmaclea]

@cshung Since the dac is built using coreclr code how do you expect these to get disconnected? Is this catching a dacize error?

[cshung]

@sdmaclea Accidental #ifdef will cause failures like this.

struct BadStruct
{
#ifdef !DACCESS_COMPILE
    int x;
#endif
   int y;
};

If it turns out that the daccess code never access x but it access y, the cross-compilation would succeed, but the generated code will access x instead of y when we ask for y.

This is not theoretical, this is a post-mortem work item for the issue https://github.com/dotnet/corefx/issues/38071 fixed by dotnet/coreclr#24798.

Catching this type of issue upstream at build time would eliminate a source of the issue once and for all.

[jkotas]

a source of the issue once and for all

You can have the same accidental ifdef in the algorithm that the layout check won't find.

We had this tool for desktop. The tool worked by comparing symbol information for coreclr.dll and cross-compiled mscordacwks.dll . It did catch a few issues, but it also generated a ton of false positives - for example, the symbols for C runtime have the same names, but different layout between platforms.

I think it would be better to spend energy on building universal DAC that is based on clearly defined and tested contracts. The universal DAC is actually going to fix this issue once and for all.

[cshung]

IMHO, it is even more important for us to have an (ideally - build time) validation that the memory layout the universal DAC will depend on matches its expectation.

Instead of using a tool that matches symbols blindly. We may consider the AsmOffsetsVerify approach. Having the dependencies spelled out manually can make it crystal clear what is being depended on, and it can also drive the number of dependencies low [for one have to work hard to author these offsets]

[dotnet-policy-service]

Due to lack of recent activity, this issue has been marked as a candidate for backlog cleanup. It will be closed if no further activity occurs within 14 more days. Any new comment (by anyone, not necessarily the author) will undo this process.

This process is part of our issue cleanup automation.

[dotnet-policy-service]

This issue will now be closed since it had been marked no-recent-activity but received no further activity in the past 14 days. It is still possible to reopen or comment on the issue, but please note that the issue will be locked if it remains inactive for another 30 days.