-
Notifications
You must be signed in to change notification settings - Fork 4.7k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Do not encode safe points with -1 offset. #104336
Changes from all commits
4bf5e03
7ecaab7
91bdf63
09e0dfb
7d2fd22
ee1a050
8b84d1f
649fabb
698dc61
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
Original file line number | Diff line number | Diff line change |
---|---|---|
|
@@ -1515,29 +1515,6 @@ void CodeGen::genExitCode(BasicBlock* block) | |
if (compiler->getNeedsGSSecurityCookie()) | ||
{ | ||
genEmitGSCookieCheck(jmpEpilog); | ||
|
||
if (jmpEpilog) | ||
{ | ||
// Dev10 642944 - | ||
// The GS cookie check created a temp label that has no live | ||
// incoming GC registers, we need to fix that | ||
|
||
unsigned varNum; | ||
LclVarDsc* varDsc; | ||
|
||
/* Figure out which register parameters hold pointers */ | ||
|
||
for (varNum = 0, varDsc = compiler->lvaTable; varNum < compiler->lvaCount && varDsc->lvIsRegArg; | ||
varNum++, varDsc++) | ||
{ | ||
noway_assert(varDsc->lvIsParam); | ||
|
||
gcInfo.gcMarkRegPtrVal(varDsc->GetArgReg(), varDsc->TypeGet()); | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. We should have correct GC info at the label after GS cookie check as cookie check has no effect on GC liveness. (maybe it did in the past?) This was just noop or was messing things up by forcing argument registers to be GC-alive when they would not have GC references in them. Perhaps it was compensating for some behavior that is long gone. There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. This was hidden because we did not allow interrupting thread on this instruction in a leaf frame (but we can and should) and in nonleaf this would not show up because this is a tailcall. |
||
} | ||
|
||
GetEmitter()->emitThisGCrefRegs = GetEmitter()->emitInitGCrefRegs = gcInfo.gcRegGCrefSetCur; | ||
GetEmitter()->emitThisByrefRegs = GetEmitter()->emitInitByrefRegs = gcInfo.gcRegByrefSetCur; | ||
} | ||
} | ||
|
||
genReserveEpilog(block); | ||
|
Original file line number | Diff line number | Diff line change |
---|---|---|
|
@@ -594,8 +594,7 @@ bool emitter::emitGenNoGCLst(Callback& cb) | |
emitter::instrDesc* id = emitFirstInstrDesc(ig->igData); | ||
assert(id != nullptr); | ||
assert(id->idCodeSize() > 0); | ||
if (!cb(ig->igFuncIdx, ig->igOffs, ig->igSize, id->idCodeSize(), | ||
ig->igFlags & (IGF_FUNCLET_PROLOG | IGF_FUNCLET_EPILOG | IGF_EPILOG))) | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I realized that including epilogs in this set was just compensating for the bug related to GS cookies and for overly conservative asserts in NativeAOT hijacker. It is fairly common on ARM64 to see: bl <somewhere>
ldp <some regs> // <-- this IP is certainly unwindable, how else can we unwind from the call above?
ldp <more regs>
ldp fp, lr, [sp], #0x60 The first instruction of an epilog is no different from a first instruction in a regular no-GC region. |
||
if (!cb(ig->igFuncIdx, ig->igOffs, ig->igSize, id->idCodeSize(), ig->igFlags & (IGF_FUNCLET_PROLOG))) | ||
{ | ||
return false; | ||
} | ||
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Matching change will need to be made in https://github.com/dotnet/diagnostics/tree/main/src/shared/gcdump so that GC info dumping in SOS works.
There is a challenge though: SOS wants to support all runtimes, so the SOS copy will need to work for both old and new GC info encoding - we will need to switch based on the current runtime version somehow.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Also, same problem exists for https://github.com/dotnet/runtime/tree/main/src/coreclr/tools/aot/ILCompiler.Reflection.ReadyToRun/Amd64
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
There is no corresponding location for arm[64]. Do we use Amd64 for all cases?
It is the RISC arches that are more interesting, since the encoding size changes.
Figured that:
// Arm, Arm64, LoongArch64 and RISCV64 use the same GcInfo format as Amd64
The arch specific behavior is done via consulting with _readyToRunReader.Machine`
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think there are no changes needed on x64 for the uses of GcInfo that do enumeration. The offsets are different, but that is a matter of
FindSafePoint(offset)
kind of use, as the offset would need to no longer do-1
adjustment in nonleaf cases. I do not see such use in ReadyToRun thing.Basically - for the use like
foreach(safePoint in ...) {foreach(slot in SlotsAt(safePoint)}
, on x64 everything should work as before.There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The RISC is more interesting as GcInfo deserializer would need to denormalize code offsets based on GcInfo version. Not just the offsets used in safepoints, there are other places.
I would expect that GcInfo deserializer that wants to support different runtimes already needs to figure the version of GCInfo. This is not the first time it changes.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The diagnostics/SOS GcInfo deserializer looks like just a copy of the one in the runtime. It is version-aware (can handle v1 and v2) and gets the version from the supplied token.
We may just need to copy/paste the new version once this change goes in.
Logged a follow-up issue for that: dotnet/diagnostics#4795