Fix struct ReturnKind on SysV AMD64. by zengandrew · Pull Request #116194 · dotnet/runtime

zengandrew · 2025-06-01T15:47:59Z

On SysV AMD64, structs returned in a float and int reg pair were being classified as RT_Scalar_XX. This causes downstream consumers (e.g., HijackFrame::GcScanRoots) to look for obj/byref's in the second int reg. Per the ABI, however, the first float is passed through a float reg and the obj/byref is passed through the first int reg. We now detect and fix this case by skipping the first float type in the ReturnKind encoding and moving the second type into the first.

Fix#115815

On SysV AMD64, structs returned in a float and int reg pair were being classified as RT_Scalar_XX. This causes downstream consumers (e.g., HijackFrame::GcScanRoots) to look for obj/byref's in the second int reg. Per the ABI, however, the first float is passed through a float reg and the obj/byref is passed through the _first_ int reg. We now detect and fix this case by skipping the first float type in the ReturnKind encoding and moving the second type into the first. Fixdotnet#115815

zengandrew · 2025-06-01T15:49:56Z

@dotnet-policy-service agree

jkotas · 2025-06-01T18:47:05Z

- return GetStructReturnKind(VarTypeToReturnKind(retTypeDesc.GetReturnRegType(0)),
- VarTypeToReturnKind(retTypeDesc.GetReturnRegType(1)));
+ {
+ var_types first = retTypeDesc.GetReturnRegType(0);


This is the right fix for backport. In main, this path is unreachable in main - the whole method can be under TARGET_X86 ifdef and simplified to only handle a single register.
@jakobbotsch How would you like to handle this?

@zengandrew Thanks so much for filing the fix here. I have cherry-picked the commit from this PR directly into the two backports (#116206, #116208).
Given the testing it appears to be unnecessary for the 9.0 backport. However 9.0 still has the code around return kinds enabled for x64. That code was removed in #110799 which is not part of 9.0. The actual PRs that made it unnecessary are #95565 and #104336 that are part of 9.0. But, just to be safe, since the code is actually running during hijack, I think we should include it as well.
For main I think we should skip the change (mainly to avoid the misleading commit history, since this code is unused). And indeed we should clean this up (cc @VSadov if you want to do it).

I have pushed a commit with the cleanup

jakobbotsch · 2025-06-04T09:27:58Z

+ if (eeClass->GetEightByteClassification(0) == SystemVClassificationTypeSSE)
+ {
+ // Skip over SSE types since they do not consume integer registers.
+ // An obj/byref in the 2nd eight bytes will be in the first integer register.
+ regKinds[0] = regKinds[1];
+ regKinds[1] = RT_Scalar;
+ }


Can ParseReturnKindFromSig be simplified too? It is only used by MethodDesc::GetReturnKind and that one has only uses from GCStress (which is under TARGET_X86) and CLRToCOMMethodFrame::GcScanRoots_Impl (which does not try to handle the multireg cases, but with a NYI assert.).
The ReturnKind enum could probably be cleaned up too after that.

The ReturnKind enum could probably be cleaned up too after that.
GCInfo decoder source is shared with diagnostic repo. It needs to support older versions of the format. The no longer used ReturnKind values need to stay for that.
Can ParseReturnKindFromSig be simplified too?
Done

VSadov · 2025-06-05T00:56:21Z

- }
-#endif // UNIX_AMD64_ABI

 if (pReturnTypeMT->ContainsGCPointers() || pReturnTypeMT->IsByRefLike())


If we have pReturnTypeMT->IsByRefLike(), should we return RT_ByRef ?
Or, if we cannot distinguish RT_Object from RT_ByRef, would RT_ByRef be safer to return?

Does pReturnTypeMT->IsByRefLike() actually imply that there must be a GC ref?
I think at C# level you can make any struct to be stack-only, it does not need to contain pointers or refs. If IsByRefLike() is true for all ref structs, there may not be a pointer.
Perhaps
pReturnTypeMT->ContainsGCPointers() should return RT_Object and
pReturnTypeMT->ContainsGCPointers() && pReturnTypeMT->IsByRefLike() should return RT_ByRef
Or maybe for simplicity just return RT_ByRef for pReturnTypeMT->ContainsGCPointers()?

It is not the part that is being fixed, but since we are touching this, and it looks a bit suspicious,...

Ok, I have done more cleanup. This method is only used for GC stress on x86 now. GC stress can tolerate RT_Illegal return (it did that before this change as well, so it is not a coverage regression).

jkotas · 2025-06-08T16:30:48Z

/azp run runtime-coreclr gcstress0x3-gcstress0xc

azure-pipelines · 2025-06-08T16:30:56Z

Azure Pipelines successfully started running 1 pipeline(s).

azure-pipelines · 2025-06-08T19:18:05Z

Azure Pipelines successfully started running 1 pipeline(s).

jkotas · 2025-06-09T06:58:43Z

/azp run runtime-coreclr gcstress0x3-gcstress0xc

azure-pipelines · 2025-06-09T06:58:52Z

Azure Pipelines successfully started running 1 pipeline(s).

jkotas · 2025-06-09T17:26:53Z

/azp run runtime-coreclr gcstress0x3-gcstress0xc

azure-pipelines · 2025-06-09T17:27:03Z

Azure Pipelines successfully started running 1 pipeline(s).

github-actionsBot added the needs-area-label An area label is needed to ensure this gets routed to the appropriate area owners label Jun 1, 2025

dotnet-policy-serviceBot added the community-contribution Indicates that the PR has been added by a community member label Jun 1, 2025

jkotas added area-CodeGen-coreclr CLR JIT compiler in src/coreclr/src/jit and related components such as SuperPMI and removed needs-area-label An area label is needed to ensure this gets routed to the appropriate area owners labels Jun 1, 2025

jkotas reviewed Jun 1, 2025
View reviewed changes

jkotas requested a review from jakobbotsch June 1, 2025 18:47

This was referenced Jun 2, 2025
[release/8.0-staging] Fix SysV first/second return register GC info mismatch #116208
Merged
[release/9.0-staging] Fix SysV first/second return register GC info mismatch #116206
Merged

Delete unreachable code
5730cd0

jkotas reviewed Jun 4, 2025
View reviewed changes

Comment threadsrc/coreclr/jit/gcencode.cpp Outdated

Update src/coreclr/jit/gcencode.cpp
9a718cb

jakobbotsch reviewed Jun 4, 2025
View reviewed changes

Cleanup MethodDesc::GetReturnKind
1760969

jakobbotsch approved these changes Jun 4, 2025
View reviewed changes

janvorli reviewed Jun 4, 2025
View reviewed changes

Comment threadsrc/coreclr/vm/method.cpp

jkotas reviewed Jun 4, 2025
View reviewed changes

Comment threadsrc/coreclr/vm/method.hpp Outdated

Update src/coreclr/vm/method.hpp
ae4fdfc

jkotas reviewed Jun 4, 2025
View reviewed changes

Comment threadsrc/coreclr/vm/method.hpp Outdated

Update src/coreclr/vm/method.hpp
c1c609e

VSadov reviewed Jun 5, 2025
View reviewed changes

Delete dead code
a5c9613

More cleanup
dbd7587

jkotas force-pushed the zengandrew-fix-115815 branch from c496662 to dbd7587Compare June 9, 2025 06:54

jkotas requested a review from VSadov June 9, 2025 06:58

Fix contract violation
44fa203

jkotas merged commit bc6f4b0 into dotnet:mainJun 9, 2025

github-actionsBot locked and limited conversation to collaborators Jul 10, 2025

Uh oh!

Conversation

zengandrew commented Jun 1, 2025

Uh oh!

zengandrew commented Jun 1, 2025

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

jkotasJun 9, 2025• edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

jkotas commented Jun 8, 2025

Uh oh!

azure-pipelinesBot commented Jun 8, 2025

Uh oh!

azure-pipelinesBot commented Jun 8, 2025

Uh oh!

jkotas commented Jun 9, 2025

Uh oh!

azure-pipelinesBot commented Jun 9, 2025

Uh oh!

jkotas commented Jun 9, 2025

Uh oh!

azure-pipelinesBot commented Jun 9, 2025

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

5 participants

jkotasJun 9, 2025•
edited
Loading