Skip to content
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

[RISC-V] Add more gcdump and gcinfo code. #94219

Merged
merged 2 commits into from
Nov 10, 2023
Merged

Conversation

viewizard
Copy link
Member

Part of diagnostics related changes (that should be synced with runtime) (SOS command gcinfo, ...).

CC @clamp03 @wscho77 @HJLeee @JongHeonChoi @t-mustafin @gbalykov

@ghost ghost added the community-contribution Indicates that the PR has been added by a community member label Oct 31, 2023
@ghost
Copy link

ghost commented Oct 31, 2023

Tagging subscribers to this area: @tommcdon
See info in area-owners.md if you want to be subscribed.

Issue Details

Part of diagnostics related changes (that should be synced with runtime) (SOS command gcinfo, ...).

CC @clamp03 @wscho77 @HJLeee @JongHeonChoi @t-mustafin @gbalykov

Author: viewizard
Assignees: -
Labels:

area-Diagnostics-coreclr, community-contribution

Milestone: -

@clamp03 clamp03 added the arch-riscv Related to the RISC-V architecture label Nov 1, 2023
src/coreclr/gcdump/gcdumpnonx86.cpp Outdated Show resolved Hide resolved
Copy link
Member

@clamp03 clamp03 left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thank you for your hard work. Please check my comments.

Comment on lines 299 to 301
#elif defined(TARGET_RISCV64)
assert(!"unimplemented on RISCV64 yet");
BYTE* pContext = (BYTE*)pRD->pCurrentContext;
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Is it implemented or unimplemented? I don't think we need to keep both codes for the future. Isn't it better to remove one? Please let me know your opinion.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Note, this is unimplemented block (and will not be implemented in this PR for sure). We stay with previous logic - assert in debug build and compile default code in release build. I can't remove any of this lines since this will broke previous logic - will not assert in debug or will not compile code in #else block.

Comment on lines 399 to 401
#elif defined(TARGET_RISCV64)
assert(!"unimplemented on RISCV64 yet");
pReg = (SIZE_T*)(pContext + rgRegisters[iReg].cbContextOffset);
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Please check and remove one.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Note, this is unimplemented block (and will not be implemented in this PR for sure). We stay with previous logic - assert in debug build and compile default code in release build. I can't remove any of this lines since this will broke previous logic - will not assert in debug or will not compile code in #else block.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Sorry. I cannot understand well. If the block is unimplemented, I don't understand why we need those default codes for release build? And pReg = (SIZE_T*)(pContext + rgRegisters[iReg].cbContextOffset); is necessary for only Release build? Could you explain for me?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We have 2 situation here: 1) without some of this code blocks you can't compile, since this blocks provide local variables definitions; 2) I can't guarantee that in release build, code will avoid "infinity loop" or something like that, in case we don't change some variables, that changed by initial logic;

This mean, in case someone will use diagnostics SOS command gcinfo (after this code will be synced with diagnostics repo) it should not hangs or sigsegv in release build.

Comment on lines 475 to 477
#elif defined(TARGET_RISCV64)
assert(!"unimplemented on RISCV64 yet");
base = GC_SP_REL;
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Please check and remove one.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Note, this is unimplemented block (and will not be implemented in this PR for sure). By default, I use same code here as arm/loongarch, since we will have same logic as arch with volatile registers, but could switch to default from #else block for sure.

Comment on lines 509 to 511
#elif defined(TARGET_RISCV64)
assert(!"unimplemented on RISCV64 yet");
pContext = (BYTE*)pRD->pCallerContext;
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Please check and remove one.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Note, this is unimplemented block (and will not be implemented in this PR for sure). We stay with previous logic - assert in debug build and compile default code in release build. I can't remove any of this lines since this will broke previous logic - will not assert in debug or will not compile code in #else block.

Comment on lines +719 to +720
FILL_REGS(pCurrentContext->R0, 33);
FILL_REGS(pCallerContext->R0, 33);
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think it is 32 because you removed PC. And please do not force-push. I want to check the number is updated when you remove PC. However, I cannot see your previous commits. Please add commits not force-push. Thank you.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I want to check the number is updated when you remove PC.

We stay with PC here since all other architectures have this logic.
Note, I removed PC only from switch in another source, not really connected to this code logic.

However, I cannot see your previous commits.

The only changes I did is:
https://github.com/dotnet/runtime/compare/ebfbce12b56e40f36c197729700479e2f276eebb..ea435f756d5bf3dc01ded976da44cb00c5ac91e7

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I see. Thank you!

@clamp03 clamp03 requested a review from jkotas November 8, 2023 01:07
@clamp03
Copy link
Member

clamp03 commented Nov 8, 2023

@jkotas Could you take a look at this PR? Thank you.

@jkotas
Copy link
Member

jkotas commented Nov 8, 2023

SOS command gcinfo,

How well does it work with so many TODOs remaining?

#endif

#if defined(TARGET_ARM) || defined(TARGET_ARM64)
BYTE* pContext = (BYTE*)&(pRD->volatileCurrContextPointers);
#elif defined(TARGET_LOONGARCH64)
assert(!"unimplemented on LOONGARCH yet");
BYTE* pContext = (BYTE*)pRD->pCurrentContext;
#elif defined(TARGET_RISCV64)
assert(!"unimplemented on RISCV64 yet");
// TODO implement risc-v code, that should care about volatile registers (same as arm/arm64 architectures)
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Add || defined(TARGET_RISCV64) to the ARM / ARM64 case above?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I am not sure we could change pointer to another size structure here and after this operate with offsets for another structure size in code below.

@viewizard
Copy link
Member Author

How well does it work with so many TODOs remaining?

In case of release build it don't show or show wrong (at least I think so) related part of output (last part with registers related block).

@viewizard
Copy link
Member Author

viewizard commented Nov 8, 2023

Correction
This PR don't change SOS gcinfo command at all, since this changes should be synced into diagnostics repo and SOS plugin should be rebuild with this code.

@jkotas jkotas merged commit 3c5123e into dotnet:main Nov 10, 2023
109 of 111 checks passed
@viewizard viewizard deleted the riscv64 branch November 10, 2023 08:19
@github-actions github-actions bot locked and limited conversation to collaborators Dec 10, 2023
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
arch-riscv Related to the RISC-V architecture area-Diagnostics-coreclr community-contribution Indicates that the PR has been added by a community member
Projects
None yet
Development

Successfully merging this pull request may close these issues.

7 participants