Snapshots without code should be architecture independent

[bkonyi]

The addition of two x64 specific stubs introduced here caused failures once the Dart SDK was rolled into the engine and built on the bots due to a mismatch of the number of base objects in a snapshot, resulting in flutter_gallery crashing when using the artifacts hosted in the cloud:

[ +457 ms] E/DartVM  ( 7300): ../../third_party/dart/runtime/vm/clustered_snapshot.cc: 5416: error: Snapshot expects 152 base objects, but deserializer provided 150
[   +4 ms] E/DartVM  ( 7300): Dumping native stack trace for thread 1c84
[        ] E/DartVM  ( 7300):   [0xd0f7c90d] Unknown symbol
[        ] E/DartVM  ( 7300):   [0xd0f7c90d] Unknown symbol
[        ] E/DartVM  ( 7300): -- End of DumpStackTrace

The artifacts Flutter distributes only include the snapshots created as part of the host_{debug,profile,release} and does not distribute the arm snapshots.

cc/ @rmacnak-google @a-siva

[mraleph]

I assume that this is fixed by cd9a42239f76e110dd73aeaac4c69a057a76ddf1?

It is a bit unclear to me what is actually happening: why would we be using an non-ARM clustered snapshot on an ARM device? It seems a waste of space to include the code for these stubs that will never be used into snapshots.

[rmacnak-google]

When we generate a snapshot without code, we include the stubs in the base objects for the vm-isolate part. This allows the VM to run isolates from snapshots with and without code in the same process. As long as the base objects are the same across architectures, the snapshots without code are compatible across architectures. This compatibility is also required for script snapshots to be portable across architectures (though they will go away with Dart 1). Flutter has been relying on this by only uploading one artifact for its debug-mode core snapshot, instead of uploading one per architecture.

Since it's introduction, DBC has had a separate stub list, so its snapshot without code have been incompatible with the rest.

[mraleph]

If we rely on this then we need to have tests for this or assertions that guarantee such compatibility.

I will try to look into changing how this works for stubs so that we can still exclude platform specific stubs from the platforms that don't use them.