Debug SAIL for Native Triggers

[jjscheel]

Technical Group

Debug TG

ratification-pkg

Debug

Technical Liaison

Tim Newsome

Task Category

SAIL model

Task Sub Category

• gcc
• binutils
• gdb
• intrinsics
• Java
• KVM
• ld
• llvm
• Linux kernel
• QEMU
• Spike

Ratification Target

3Q2023

Statement of Work (SOW)

SOW link

SOW Signoffs: (delete those not needed)

• Task group liaison sign-off date:
• Development partner sign-off date:

Waiver

• Freeze
• Ratification

Pull Request Details

• Sail PR - closed
• New Sail PR - open

[jjscheel]

@junambi, as you begin to start this work, I'd appreciate an outlook for when you think this work might be completed. I suggest we think about it in terms of steps and put dates for each:

• Planning complete
• Development completed (ready to submit first PR)
• All PRs accepted (done)

[junambi]

Working on a flow for the implementation.

[jjscheel]

@timsifive, @pdonahue-ventana, any volunteers to help here yet?

[timsifive]

I haven't heard from anyone.

[jjscheel]

Comment from most recent ARC minutes (July 10) - link

• Debug 1.0: Review has started of the latest submitted spec, but just review of all the changes since the last Debug 1.0 draft spec was submitted, reviewed, and approved. Review of this has started, with initial discussion of one of the more notable backward-incompatible changes (between v1.0 and the ratified v0.13). This relates with abstract commands and the data registers to support more efficient FPGA implementations. After further discussion in next week's ARC meeting, John will be providing ARC feedback and guidance to the Debug TG. Likely other items of feedback that arise will also be provided.
• Review of the latest Debug and Pointer Masking specs (along with the S*deleg extensions) are expected to continue next week.

Also note, this remains on the list of future DevPartners activities. It will be addressed AFTER Pointer Masking and the Floating Point gap work work (Zdinx, Zhinx).

[jjscheel]

@UmerShahidengr, any chance that 10xEngineers has someone to pick this up and drive to conclusion?

[jjscheel]

@UmerShahidengr, any feedback on your ability to start work here?

[UmerShahidengr]

@muhammad-maarij-zeeshan can you please look at it?
@jjscheel we will do it, you can change its status and set up its end date to be end of 2Q2024 (i.e, June 2024)

[jjscheel]

Thanks, @UmerShahidengr. Can you please make sure that @muhammad-maarij-zeeshan sends an email to [email protected] to request his account? Then, I'll take care of the other DevPartner enablement.

[jjscheel]

@UmerShahidengr, has work started here?

[UmerShahidengr]

@jjscheel it has not been started yet because of resource limitation, but it is in my priority list. Keep it assigned to me, I will look into it soon.

[jjscheel]

Thanks, @UmerShahidengr. As we discussed, we will need to complete the code to the point of submitting a PR in order to be able to ratify the spec without a waiver from the TSC. Given that the spec has completed Public Review and is being updated, it could be ready for ratification within the next 1-2 months.

[jjscheel]

@UmerShahidengr, any progress here?

[UmerShahidengr]

@jjscheel we will add the 1st PR within next 2 weeks.

[UmerShahidengr]

Update April 30th, 2024:
@HAMZA-AFZAL404 has been working on this SoW. We are still in developing phase.

[UmerShahidengr]

@jjscheel, I have a query for this issue, We have been adding the functionality of every trigger register (Registers have been implemented) but, every trigger register is accessed by Debug Mode and Debug Mode is not implemented at all in Sail. Implementing full Debug Mode in Sail is a big problem as it has a huge spec and a huge stuff is to be implemented.
My question is what is the scope of this SoW? Is it just to add the functionality of the trigger registers and making them writable in M mode? Or to implement full Debug Mode and then extend it for trigger?
According to SoW, the requirement is to extend the SAIL model to implement the Trigger Module in Debug spec 1.0, but there is a confusion around the implementation of Debug Mode.
CC: @HAMZA-AFZAL404

[jjscheel]

@UmerShahidengr, my understanding of the intent of this SOW is only to implement the Trigger Module to best of the support of EVERY register possible. While we are here, if we can extend the base register support with reasonable work, please do so as a separate PR, but you need not feel like you have to cover unimplemented registers. Those can come in when ready.

@billmcspadden-riscv, do you agree?

@timsifive and @pdonahue-ventana , does this meet your expectations?

[pdonahue-ventana]

I think that there's no need to implement trace-related actions and there's no need to implement Debug Mode which is not directly related to the Trigger Module. You can't get into Debug Mode without implementing non-ISA features like the Debug Module which are beyond the scope of SAIL. Therefore, the goal would be to implement triggers with action=0 and dmode=0. Just native (self-hosted) debug.

[UmerShahidengr]

Update June 11th, 2024:
The Native Trigger PR is available here, since Debug mode is not available in Sail so only register definitions (tdata1, tdata2 etc.) could have been added as part of Sdtrig extension. @Mudassir10X has worked on this, and he has been in contact with @billmcspadden-riscv on this implementation.

[jjscheel]

Thanks for update, @UmerShahidengr!

@billmcspadden-riscv, how difficult is it going to be implement basic debug mode?

[UmerShahidengr]

Update June 25th,2024:
We had a meeting with Tim Newsome and @billmcspadden-riscv almost 10 days ago, and we discussed the logistics of Sdtrig implementation, we have concluded that basic native trigger support can be added in Sail without adding Debug mode support, @Mudassir10X has been working on this one, and we will be having meetings with Tim Newsome and Bill every 15 days to discuss the progress. So far, the basic task list has already been defined, we will keep you updated with the progress.

[UmerShahidengr]

Update July 23rd, 2024:
Unfortunately @Mudassir10X is no longer working with 10xEngineers, there has been no update on this SoW. New team member will be assigned to this project and that new person will complete it.

[jjscheel]

Thanks for the update, @UmerShahidengr. I know this is unplanned, but please make this your (near) top priority to find a replacement. The waiver work has become the critical path to ratification for the Debug specification and this is one piece of it.

[UmerShahidengr]

Update August 6th, 2024
No major update on it. One trainee has been assigned as replacement of Mudassir, but it will take some time to ramp him up for this task.

[jjscheel]

@UmerShahidengr, per my email, we need to understand who the trainee is and how soon they will be able to work with @billmcspadden-riscv to complete this work.

[UmerShahidengr]

@jjscheel, after your email, we (Bilal and I) had conversation, one engineer will start working on this project full time from Sept 1st, we are estimating it to complete it till mid-October.

[UmerShahidengr]

@YazanHussnain-10x will be working on this SoW full time from Sept 1st.

CC: @jjscheel

[jjscheel]

Please ensure that Yazan applies for a RISC-V Portal id by sending an email to [email protected] with me on cc. I'll handle everything else after that. Welcome, YazanHussnain-10x!

[jjscheel]

Ping: Please ensure that Yazan applies for a RISC-V Portal id by sending an email to [email protected] with me on cc. I'll handle everything else after that. Welcome, YazanHussnain-10x!

[YazanHussnain-10x]

Update: September 22nd, 2024

Open Question
If the trigger is configured to match and fire on the Load address, in that case, xepc is set to the virtual address of the instruction matched. When returning from the break-point exception trap, the instruction is re-executed, and the configured trigger matches and fires again. How to prevent it from firing again on the same instruction?

Update

1. Sdtrig Extension CSRs have been implemented.
2. Both solutions for the re-entrancy problem have been implemented.
3. The Icount Trigger, itrigger, and etrigger have been implemented.
4. The Match Control Type 6 Trigger remains to be implemented.

I verified the functionality with a basic test, but I need some ACTs for the Native trigger to verify it properly and to ensure that it should not behave strangely.

[pdonahue-ventana]

Disable the trigger in question, single step, reenable the trigger, resume.

[YazanHussnain-10x]

Thank, you @pdonahue-ventana

[rtwfroody]

Both solutions for the re-entrancy problem have been implemented.

Note that only one of the two solutions should be enabled at any one time. No real hardware will implement both.

[UmerShahidengr]

Update October 1st, 2024:
Basic Implementation is done, but we are getting some issues in the trap handler when trigger is firing upon returning to the trap due to illegal instruction, trap handler is not reserving the mepc value to take to code back to the test. Trap Handler requires some updates to handle such nested exception cases.
Basic Implementation is done, and we are waiting for the ACTs to check the implementation

[rtwfroody]

Initial ACT tests are at riscv-non-isa/riscv-arch-test#487. They're not fully reviewed but they should work.

[YazanHussnain-10x]

Update October 4th, 2024:
Match control trigger implementation is done. I tested the functionality, with the basic test, both on RV32 and RV64. Now testing with the ACTs mentioned by @rtwfroody. I raised the PR on the sail-riscv repo for the initial review

[jjscheel]

It appears that the new PR is here: riscv/sail-riscv#573

What are the plans for Mudassir's older PR? riscv/sail-riscv#486

[UmerShahidengr]

@jjscheel, the old one will be closed by Mudassir soon.

[UmerShahidengr]

Update October 29th, 2024:
The PR is in review, @rtwfroody has been reviewing the PR, @YazanHussnain-10x has been working on this one, review process is going smoothly.

[jjscheel]

Old PR closed by @billmcspadden-riscv. THANKS!

[jjscheel]

@rtwfroody and @pdonahue-ventana, thanks for your reviews and comments on the PR. If you've completed the review of all code in the PR, the first question we need to answer is whether we believe the test are functionally complete. If so, we can conclude the Freeze waiver for Sail. Can you share your thoughts/comments here? If your answer is no, please clearly identify what you'd like to see resolved to be considered complete.

[pdonahue-ventana]

Is the question about whether the Sail is complete (which I think is the topic here) or whether the tests (in riscv-non-isa/riscv-arch-test#487) are complete?

[pdonahue-ventana]

Answering my own question: I think that you just copied the text above from the ACT issue so I'll assume that the question here is about Sail.

I think that the Sail is as complete as necessary. Things like VS/VU mode support are known to be missing, but Sail doesn't support those modes in general so the Sdtrig support can't be expected to add full support for the hypervisor extension. There are a few other minor things like tmexttrigger (asynchronous triggers) that are also missing but I don't expect that Sail would ever support that. I'm satisfied with what's here.

[jjscheel]

@pdonahue-ventana, yes your assumptions and guess as to its motivation are correct. This was a copy and paster error. Indeed I was wondering if the Sail was complete as defined by this SOW (which is defined in the first entry of this issue), which in turn links to Tim's original SOW doc -- SOW link.

Please review it one final time and confirm your answer.

@timsifive, would love your review and thoughts too when you have a moment.

[pdonahue-ventana]

timsifive is now @rtwfroody

[jjscheel]

@rtwfroody, would love your review and thoughts too when you have a moment.

[pdonahue-ventana]

I believe that the Sail work meets the SOW and actually exceeds it in some ways (e.g. support for all match types, not just three of them).

I don't know whether to laugh or cry about this line from the SOW: "Needed for end of 2022 ratification"