XmmYmmStateSupport executes xgetbv without checking if instruction is available first

[cesarblum]

We're seeing test failures on Mac on Travis (and my own personal Mac) on Kestrel test runs. The dotnet process is exiting with exit code 132, which means the process was killed with SIGILL meaning it attempted to execute an illegal instruction.

On lldb I see that XmmYmmStateSupport uses xgetbv, which is not available on older processors (e.g. my Mac is from 2011 and has an Intel Core 2 Duo processor in it):

xUnit.net .NET CLI test runner (64-bit .NET Core osx.10.12-x64)
  Discovering: Microsoft.AspNetCore.Server.Kestrel.FunctionalTests
  Discovered:  Microsoft.AspNetCore.Server.Kestrel.FunctionalTests
  Starting:    Microsoft.AspNetCore.Server.Kestrel.FunctionalTests
Process 18423 stopped
* thread dotnet/coreclr#17: tid = 0x8ece5, 0x0000000101a03646 libcoreclr.dylib`XmmYmmStateSupport + 6, stop reason = EXC_BAD_INSTRUCTION (code=EXC_I386_INVOP, subcode=0x0)
    frame #0: 0x0000000101a03646 libcoreclr.dylib`XmmYmmStateSupport + 6
libcoreclr.dylib`XmmYmmStateSupport:
->  0x101a03646 <+6>:  xgetbv 
    0x101a03649 <+9>:  andl   $0x6, %eax
    0x101a0364c <+12>: cmpl   $0x6, %eax
    0x101a0364f <+15>: sete   %al

[cesarblum]

Got curious and was looking a bit more into this. It's not that my processor (and likely Travis' agents' processors) doesn't have that instruction, but the OS needs to enable its use.

[muratg]

cc @gkhanna79

[gkhanna79]

@muratg This change is only in master. What is it blocking? What is the OSX version on the machines in question?

[cesarblum]

@gkhanna79 We've seen it on 10.11 and 10.12. But it's more about the processor than the OS. I think OS X only enables XSAVE on newer machines.

This is blocking our test runs on Mac on Travis.

I'm already working on a fix for it, will submit a PR as soon as I test it.

[gkhanna79]

Thank you @CesarBS. I will assign this issue to you in that case :)

[gkhanna79]

CC @janvorli