AR: tcontrol.mie applies to all traps, not just breakpoints

[Tim Newsome (timsifive)]

Reverts #723, which would result in mepc etc. being clobbered if a breakpoint trigger would fire in the most privileged mode.

Specifically, consider:

1. icount is set so that it'll trigger on the first instruction of an exception handler.
2. Code takes an exception, saving mepc etc.
3. Now icount fires causing a breakpoint exception, clobbering mepc.

[Paul Donahue (pdonahue-ventana)]

This makes sense and it's kind of like the general mstatus.MIE and mstatus.MPIE behavior. When you enter M mode on any trap then you clear MIE and you can't take an interrupt until the handler has done whatever is necessary to reenter (e.g. push mepc on the stack) and then indicate that it has done so by setting MIE. Similarly, when you enter M mode on any trap, you clear mte and can't take a breakpoint until the handler has indicated it is ready by setting mte again.

It's too bad that you can't debug the handler but that's just a limitation, just like handlers have to avoid traps (no illegal instructions, no interrupts, no load/store that could page fault, etc.) during this early part of the handler. You can still debug handlers with an external debugger (which may be less convenient for someone who was hoping to not need to connect to JTAG but that's life).