-
Notifications
You must be signed in to change notification settings - Fork 4.9k
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
[SuperPMI] Support spmi-asmdiffs on Arm64 #48683
Conversation
… and move them to src/coreclr/ToolBox/superpmi/superpmi-shared
…ompileResult::applyRelocs in src/coreclr/ToolBox/superpmi/superpmi-shared/compileresult.cpp
…r/ToolBox/superpmi/superpmi-shared/compileresult.cpp
…superpmi/superpmi-shared/compileresult.cpp
…n src/coreclr/ToolBox/superpmi/superpmi-shared/compileresult.cpp
…i/superpmi-shared/compileresult.cpp
…/ToolBox/superpmi/superpmi/neardiffer.cpp
…red/spmiutil.cpp src/coreclr/ToolBox/superpmi/superpmi-shared/spmiutil.h
…perpmi/superpmi-shared/spmiutil.cpp src/coreclr/ToolBox/superpmi/superpmi-shared/spmiutil.h
…AGEBASE_REL21 and IMAGE_REL_ARM64_PAGEOFFSET_12A in compileresult.cpp
…x/superpmi/superpmi-shared/spmiutil.cpp src/coreclr/ToolBox/superpmi/superpmi-shared/spmiutil.h
…_PCREL IMAGE_REL_BASED_THUMB_BRANCH24 on Arm in compileresult.cpp
4fa622b
to
30023dd
Compare
if ((section_begin <= address) && (address < section_end)) // A reloc for our section? | ||
{ | ||
if (!FitsInThumb2BlRel24(delta)) | ||
{ |
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 was not sure what to do here. IIRC, if such overflow occurs in real product during crossgen the JIT would be required to re-compile the method without using this type of relocation.
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.
@BruceForstall Any opinion if this is desired behavior? What would/should happen during spmi collect when such relocation overflow occurs? Would the corresponding method context be included in the final collection?
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'm not sure what would happen during spmi collection if it failed. It's supposed to throw and retry, but the retry logic for relocs in crossgen1 seems to be dependent on m_fNGenLastRetry, but I can't find how that ever gets set to true (because it's dependent on fNgenLastRetry, which is never set to true).
It looks like crossgen2 always returns IMAGE_REL_BASED_THUMB_BRANCH24 with no provision for overflow.
I would guess spmi would only record the retry compilation, but it's not clear that ever happens.
With this change I could successfully run spmi-asmdiffs on
No errors due to "Unknown reloc type" or "Decoding has failed" Note that I had to remove this line that was setting @BruceForstall @dotnet/jit-contrib PTAL |
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 are a couple other TARGET ifdefs it seems like you could address while you're at it:
TypeUtils::GetCorInfoTypeName() // simple output code
CallUtils::HasRetBuffArg() // unreferenced; can just be deleted
…Arm64 in neardiffer.cpp
…perpmi/superpmi-shared/compileresult.cpp
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.
LGTM. Thanks for finding the sizeof() cases. I'm sure we'll find more cross-target issues over time, but this is a good update.
if ((section_begin <= address) && (address < section_end)) // A reloc for our section? | ||
{ | ||
if (!FitsInThumb2BlRel24(delta)) | ||
{ |
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'm not sure what would happen during spmi collection if it failed. It's supposed to throw and retry, but the retry logic for relocs in crossgen1 seems to be dependent on m_fNGenLastRetry, but I can't find how that ever gets set to true (because it's dependent on fNgenLastRetry, which is never set to true).
It looks like crossgen2 always returns IMAGE_REL_BASED_THUMB_BRANCH24 with no provision for overflow.
I would guess spmi would only record the retry compilation, but it's not clear that ever happens.
Hello @echesakovMSFT! Because this pull request has the p.s. you can customize the way I help with merging this pull request, such as holding this pull request until a specific person approves. Simply @mention me (
|
The failure in runtime (CoreCLR Pri0 Runtime Tests Run windows arm64 checked) is not relevant
tracked by #48820 |
#ifdef TARGET_*
inCompileResult::applyRelocs
in compileresult.cpp to runtime checks and allow SuperPMI to work with cross-architecture jits during asmdiffs (e.g. clrjit_win_arm64_x64.dll)CompileResult::applyRelocs
and separate platform specific relocations (x86, arm64, 64-bit targets) from platform agnostic relocationsIMAGE_REL_ARM64_BRANCH26
,IMAGE_REL_ARM64_PAGEBASE_REL21
andIMAGE_REL_ARM64_PAGEOFFSET_12A
inCompileResult::applyRelocs
.IMAGE_REL_BASED_THUMB_MOV32
,IMAGE_REL_BASED_REL_THUMB_MOV32_PCREL
andIMAGE_REL_BASED_THUMB_BRANCH24
inCompileResult::applyRelocs
.repAllocMem
inNearDiffer::compare
in neardiffer.cpp. On Arm64 methods that have literal (constant) pools will fail decoding since the pools are appended to the methods code section and the size of code section reported byrepAllocMem
will include the constant pool. In order to avoid decoding of the constant pools and adjust code section to only contain executable portion - userepCompileMethod
inNearDiffer::compare
.