2013/8/12 Julius Baxter <[email protected]>: > On Mon, Aug 12, 2013 at 12:12 PM, Franck Jullien > <[email protected]> wrote: >> Hi Julius, >> >> 2013/8/12 Julius Baxter <[email protected]>: >>> On Sun, Aug 11, 2013 at 11:06 PM, Franck Jullien >>> <[email protected]> wrote: >>>> Hi, >>>> >>>> In the original patch we substituted the pc with the npc value while >>>> flushing the pipe after a dbg_stall disassertion. This doesn't work >>>> everytime because npc might not be always equal the the bp address. >>>> >>>> In this patch, we save the npc content when the dbg_stall occurs >>>> (saved_npc). This value will be used to set the pc after a dbg_stall >>>> disassertion. >>> >>> Hi Franck, >>> >>> This makes sense. However, what happens if we hit a breakpoint and >>> then set a new NPC via the debugger? It looks like we can resume from >>> the saved PC only, and not a newly written one. I think you'll need a >>> mechanism for detecting a write to the NPC while the CPU is stalled >>> and resuming from that address. >>> >>> Also, this saved address doesn't look like it's accessible by reading >>> the NPC in SPR space. Surely being able to read the actual NPC you're >>> going to resume from is important. I presume the NPC register doesn't >>> hold the right value here, and if so, that's not great. >>> >>> Or maybe I'm not reading the patch correctly? >>> >> >> To be honest, I didn't ask myself all those questions :) I just patch >> it to make it work in my test case. >> I'll see what I can do. I just wanted to close the debug thing case. > > How about you use the condition where you save the NPC in the new > register to just write to the actual NPC SPR internally (or stop it > from being updated, whatever the case may be)? That would be a small > change, and it would then be visible to the debugger and you could > change it if you liked. >
Well, I tried to do this but it's not as trivial as it sounds. Writing the NPC when we get the dbg_stall signal rising has some strage side effects. We might check some other conditions to wait everything has finished before writing it. However, the posted patch is working without modification. As a matter of fact, if you write the NPC via your favorite debugger, you'll generate a pipeline flush which causes du_except_stop to be cleared and du_flush_pipe will never be triggered. So the saved_npc will be used only if nobody writes the NPC before we unstall the processor. Finally, this patch is not really usefull because we can (and we do in openocd [1], it has been suggested by Yann Vernier) write the NPC with the breakpoint value while we enter the debugger. This will flush the pipeline and ensure we'll execute the instruction where we stopped. [1] https://github.com/Franck79/openOCD/blob/auto_tdesc/src/target/openrisc/or1k.c#L633 Franck. _______________________________________________ OpenRISC mailing list [email protected] http://lists.openrisc.net/listinfo/openrisc
