controlling the cheri mode to enter when entering debug mode

[tariqkurd-repo]

fixes #322

[tariqkurd-repo]

we're now thinking about allocating an unused bit in DCSR which will specify which mode to enter on debug mode entry, or keep using the bit in dinfc, the point is to enter using the mode specified in the CSR

[arichardson]

One minor questions otherwise this looks good to me.

I think it is important that we can attach both an updated one (e.g. OpenOCD) as well as an unmodified debugger to the core since it is common to use more than one debugger for a given core depending on who is debugging/what is being debugged.

[andresag01]

@tariqkurd-repo: Could we remove this text in the spec? This change is based on feedback from porting debuggers to CHERI RISC-V:

This section is preliminary as no-one has yet built debug support for CHERI-RISC-V so
change is likely.

[tariqkurd-repo]

@tariqkurd-repo: Could we remove this text in the spec? This change is based on feedback from porting debuggers to CHERI RISC-V:

This section is preliminary as no-one has yet built debug support for CHERI-RISC-V so
change is likely.

done

[andresag01]

I broadly agree with this change. However, it would be best if we did not have MODESW writing dinfc when executing in debug mode. First, its awkward to change the behavior of this instruction based on the privileged mode. And second, we already have another well-defined mechanism to change the m-bit in dinfc using csrr, scmode and csrw which we can fully execute from the program buffer given that CHERI RISC-V requires the program buffer to have at least 4 entries.

@arichardson : What do you think?

[arichardson]

I broadly agree with this change. However, it would be best if we did not have MODESW writing dinfc when executing in debug mode. First, its awkward to change the behavior of this instruction based on the privileged mode. And second, we already have another well-defined mechanism to change the m-bit in dinfc using csrr, scmode and csrw which we can fully execute from the program buffer given that CHERI RISC-V requires the program buffer to have at least 4 entries.

@arichardson : What do you think?

I did not realize that it was possible to have pcc in debug mode, I though it always used a program buffer without a real pc. Your explanation makes sense and I think not having it affect dinfc.mode is fine.

Alternatively, for implementations that have a PCC in debug mode and support modesw, you could copy PCC.mode into dindc.mode at the end of debug mode execution, but I'm not convinced that's needed. All we really need is a one time selection on debugger startup and for that the CSR write seems fine.

[arichardson]

I broadly agree with this change. However, it would be best if we did not have MODESW writing dinfc when executing in debug mode. First, its awkward to change the behavior of this instruction based on the privileged mode. And second, we already have another well-defined mechanism to change the m-bit in dinfc using csrr, scmode and csrw which we can fully execute from the program buffer given that CHERI RISC-V requires the program buffer to have at least 4 entries.
@arichardson : What do you think?

I did not realize that it was possible to have pcc in debug mode, I though it always used a program buffer without a real pc. Your explanation makes sense and I think not having it affect dinfc.mode is fine.

Alternatively, for implementations that have a PCC in debug mode and support modesw, you could copy PCC.mode into dindc.mode at the end of debug mode execution, but I'm not convinced that's needed. All we really need is a one time selection on debugger startup and for that the CSR write seems fine.

Alternatively, we could say for implementations that have a real pcc in debug mode, the m bit if dinfc is a view of the PCC mode bit?

[tariqkurd-repo]

If there is a PCC then yes, it will be another view of the same bit. This isn't currently stated.

…

On Fri, 20 Sept 2024, 18:44 Alexander Richardson, ***@***.***> wrote: I broadly agree with this change. However, it would be best if we did not have MODESW writing dinfc when executing in debug mode. First, its awkward to change the behavior of this instruction based on the privileged mode. And second, we already have another well-defined mechanism to change the m-bit in dinfc using csrr, scmode and csrw which we can fully execute from the program buffer given that CHERI RISC-V requires the program buffer to have at least 4 entries. @arichardson <https://github.com/arichardson> : What do you think? I did not realize that it was possible to have pcc in debug mode, I though it always used a program buffer without a real pc. Your explanation makes sense and I think not having it affect dinfc.mode is fine. Alternatively, for implementations that have a PCC in debug mode and support modesw, you could copy PCC.mode into dindc.mode at the end of debug mode execution, but I'm not convinced that's needed. All we really need is a one time selection on debugger startup and for that the CSR write seems fine. Alternatively, we could say for implementations that have a real pcc in debug mode, the m bit if dinfc is a view of the PCC mode bit? — Reply to this email directly, view it on GitHub <#370 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AOCTJAGK5LX675QSR7CL6ZTZXRNGZAVCNFSM6AAAAABOLZSSD2VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDGNRUGIYTGNZSG4> . You are receiving this because you were mentioned.Message ID: ***@***.***>