fix incorrect register number in npc #11
Open
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Follow up to f198eb6
However, I personally recommend keeping this incorrect register number in both npc and nemu 's trap.S and leave it as a part of "3-2 恢复上下文" (maybe add a hint)
This is because locating this bug requires a decent amount of effort, and students are compelled to meticulously check the structure of the frame prepared by trap.S.
It presents a great opportunity to enhance students' ability to use debugging tools. During this debugging session, students mush figure out exactly what is stored and loaded during content switch and why such a tiny difference will leads to the corruption of the frame ( for example: in yield-os, it stops at first B and not switching back to A). This will also enforce " 我乱改一通, 居然过了, 嘿嘿嘿", given that they will no pass (at least in RISC-V).
By the way this bug can be described as "the disparity in add/sub of sp, which leading the stack pointer drift 4 bytes every times a context switch occours in __am_asm_trap. This discrepancy is the result of a diffence between the value of CONTEXT_SIZE and sizeof(Context)). CONTEXT_SIZE is defined as (NR_REGS + 3 + 1) * XLEN. NR_REGS is for gpr, and 3 is for csr, obviously. Then WTF (f for friendly) is that 1? Anyway, I have to expand the Context struct to match that."
With that being said. This pitfall only exist in RISC-V. Which is a little bit unfair. Or maybe just forget about what I just said...
省流助手: 我觉得这个bug可以留着,因为这是个不错的练习。