Hi @BruceForstall, I made the changes to revert the raw byte code in contetx2.S. Looks like some builds are still failing: OSX/tvOS, linux with GCC and musl.

Are these in this location because it mimics the layout of XSAVE? Or is it arbitrary? Why are these named "Egpr16" instead of just "R16"?

Also regarding this question, I have renamed the registers, and the layout should be arbitrary, we use __cpuid(0D, featureIndex) to query the size and offset of the XSTATE feature, and then load/store them into a abstracted data structure context. Detail behavior is defined in CONTEXTToNativeContext in context.cpp. So I think we don't need to change the layout.

But I do have another open to discuss, I've logged the details in context.cpp. It would be much appreciated if you could share some thoughts.

I presume we will never support APX on OSX/tvOS or any Apple product, since they are actively deprecating Intel processor support. So the build should work around that with FEATURE_APX ifdefs or similar. If GCC and musl don't support an updated assembler yet, then I guess the change to symbolic code can't be made.

But I do have another open to discuss, I've logged the details in context.cpp. It would be much appreciated if you could share some thoughts.

This is a question about CONTEXT handling in the PAL -- @janvorli or @jkotas might be better to answer.

@Ruihan-Yin there is no need to copy the contents of the CONTEXT in one block. You can copy the APX part separately. It was just a convenience when there was one extra block, so we could do a single copy.

@Ruihan-Yin there is no need to copy the contents of the CONTEXT in one block. You can copy the APX part separately. It was just a convenience when there was one extra block, so we could do a single copy.

Thanks for the clarification, I will make the changes accordingly.

I presume we will never support APX on OSX/tvOS or any Apple product, since they are actively deprecating Intel processor support. So the build should work around that with FEATURE_APX ifdefs or similar. If GCC and musl don't support an updated assembler yet, then I guess the change to symbolic code can't be made.

But I do have another open to discuss, I've logged the details in context.cpp. It would be much appreciated if you could share some thoughts.

This is a question about CONTEXT handling in the PAL -- @janvorli or @jkotas might be better to answer.

Now that we still have dependency on GCC and musl, we can let the raw byte code stay for a little longer. But I can still cover the needed changes for renaming and context copy in this PR