The package runtime export data embedded into the compiler via builtin.go intentionally differs from package runtime's actual export data. This works because builtin.go's and runtime.a's export data do not overlap, so cmd/compile never notices that builtin.go does not actually match package runtime.

Commit f28bbb7 was reverted (9877900) because it increased the amount of differing export data provided by builtin.go. In isolation, this isn't problematic. But @aclements discovered that adding a sel *hselect field to runtime.sudog caused runtime.a to start exporting a type definition for runtime.scase, which the compiler then did complain about not matching the scase type definition from builtin.go.

Making builtin.go match runtime.a 100% is one possible option, but it's non-trivial because it involves pulling in a lot more types. It would also require builtin.go's package runtime to start using package unsafe (for unsafe.Pointer), which leads to its own problems because it's supposed to be a "safe" package.

This CL is about investigating ways to make cmd/compile more robust against conflicts between builtin.go and runtime.a.