Jumps and branches in Program Buffer

[Deepak Panwar]

Hi,

We are trying to under the debug spec and I have few questions related to Program Buffer.

1. The spec mentions that jumps are allowed in the program buffer. What about relative branches and if they are allowed what will be the PC when the core is in Debug Mode?

2. If the core jumps out of the Program Buffer, then I assume it's the responsibility of the debugger to put an ebreak or return at the jump location. 

3. Is it possible to put 2 compressed instruction in a Program Buffer entry or the upper 16 bits always needs to be 0 if there is a compressed instruction?

Thanks,

Deepak

[Megan Wachs]

On Wed, May 2, 2018 at 9:53 AM, Deepak Panwar <panwar...@gmail.com> wrote:

Hi,

We are trying to under the debug spec and I have few questions related to Program Buffer.

1. The spec mentions that jumps are allowed in the program buffer. What about relative branches and if they are allowed what will be the PC when the core is in Debug Mode?

It's not strictly required that the Program Buffer be "executable" with an address memory. You probably would want to do an aiupc instruction to determine where the Program Buffer is (if anywhere).

 

2. If the core jumps out of the Program Buffer, then I assume it's the responsibility of the debugger to put an ebreak or return at the jump location. 

Yes, otherwise the debugger can potentially lose control and there isn't really a way to get it back.

 

3. Is it possible to put 2 compressed instruction in a Program Buffer entry or the upper 16 bits always needs to be 0 if there is a compressed instruction?

If the program buffer is only 1 word, you can't (it's a special case in the spec). Otherwise you can consider it like general executable RAM and you can put 2 compressed instructions in a 32 bit program buffer word.

Thanks,

Deepak

--
You received this message because you are subscribed to the Google Groups "RISC-V Debug Group" group.
To unsubscribe from this group and stop receiving emails from it, send an email to debug+unsubscribe@groups.riscv.org.
To post to this group, send email to de...@groups.riscv.org.
Visit this group at https://groups.google.com/a/groups.riscv.org/group/debug/.
To view this discussion on the web visit https://groups.google.com/a/groups.riscv.org/d/msgid/debug/39241c1d-fe8f-427f-959e-a4e56c976906%40groups.riscv.org.

--

Megan A. Wachs

Engineer | SiFive, Inc 

1875 South Grant Street
Suite 600
San Mateo, CA 94402

me...@sifive.com

[Deepak Panwar]

Hi Megan,

Thanks for the reply. That was very useful. I have few more follow up questions after going through the Appendix A/B.

Below is the paragraph from Appendix A.2

To execute an abstract command, the DM first populates some internal words of program buffer according to command. When transfer is set, the debugger populates these words with lw <gpr>, 0x400(zero) or sw 0x400(zero), <gpr>. 64- and 128-bit accesses use ld/sd and lq/sq respec- tively. If transfer is not set, these instructions are populated as nops. If execute is set, execution continues to the debugger-controlled Program Buffer, otherwise the debug module causes a ebreakto execute immediately.

1. Does it mean that even for Access Register command (no execute), the debugger is going to populate ld/st instructions in the program buffer to copy data from gpr/csr into the data0 DM register? We are thinking of doing Execution based debugging since that's what Lauterbach also implemented. The problem is that since core is still running in debug mode (looping in park loop), the only way to read the gpr/csr is either a new mux path or jump to the program buffer and read/write the gpr/csr using ld/st instructions.

2. We are thinking all the DM registers can be memory mapped so that core can write to them in the debug handler.  Can you think of any issue with that?

Thanks,

Deepak

On Wednesday, May 2, 2018 at 1:08:06 PM UTC-5, Megan Wachs wrote:

On Wed, May 2, 2018 at 9:53 AM, Deepak Panwar <panwar...@gmail.com> wrote:

Hi,

We are trying to under the debug spec and I have few questions related to Program Buffer.

1. The spec mentions that jumps are allowed in the program buffer. What about relative branches and if they are allowed what will be the PC when the core is in Debug Mode?

It's not strictly required that the Program Buffer be "executable" with an address memory. You probably would want to do an aiupc instruction to determine where the Program Buffer is (if anywhere).

 

2. If the core jumps out of the Program Buffer, then I assume it's the responsibility of the debugger to put an ebreak or return at the jump location. 

Yes, otherwise the debugger can potentially lose control and there isn't really a way to get it back.

 

3. Is it possible to put 2 compressed instruction in a Program Buffer entry or the upper 16 bits always needs to be 0 if there is a compressed instruction?

If the program buffer is only 1 word, you can't (it's a special case in the spec). Otherwise you can consider it like general executable RAM and you can put 2 compressed instructions in a 32 bit program buffer word.

Thanks,

Deepak

--
You received this message because you are subscribed to the Google Groups "RISC-V Debug Group" group.

To unsubscribe from this group and stop receiving emails from it, send an email to debug+un...@groups.riscv.org.

To post to this group, send email to de...@groups.riscv.org.
Visit this group at https://groups.google.com/a/groups.riscv.org/group/debug/.
To view this discussion on the web visit https://groups.google.com/a/groups.riscv.org/d/msgid/debug/39241c1d-fe8f-427f-959e-a4e56c976906%40groups.riscv.org.

[Megan Wachs]

Actually thanks for pointing this out, there is some confusion there because we are saying "debugger" in one place where we mean "Debug Module". Hilighting the mistakes below, will file an issue on the spec.

On Thu, May 3, 2018 at 9:54 AM, Deepak Panwar <panwar...@gmail.com> wrote:

Hi Megan,

Thanks for the reply. That was very useful. I have few more follow up questions after going through the Appendix A/B.

Below is the paragraph from Appendix A.2

To execute an abstract command, the DM first populates some internal words of program buffer according to command. When transfer is set, the debugger (should say "Debug Module") populates these words with lw <gpr>, 0x400(zero) or sw 0x400(zero), <gpr>. 64- and 128-bit accesses use ld/sd and lq/sq respec- tively. If transfer is not set, these instructions are populated by the Debug Module as nops. If execute is set, execution continues to the debugger-controlled Program Buffer, otherwise the debug module causes a ebreakto execute immediately.

1. Does it mean that even for Access Register command (no execute), the debugger is going to populate ld/st instructions in the program buffer to copy data from gpr/csr into the data0 DM register?

[MW]: No, sorry for the confusion. The Debugger doesn't have to do this. As shown in the corrected text above, one Debug Module implementation described in A.2 is that the Debug Module will populate these "hidden" program buffer words itself based on the Access Register command.

 

We are thinking of doing Execution based debugging since that's what Lauterbach also implemented. The problem is that since core is still running in debug mode (looping in park loop), the only way to read the gpr/csr is either a new mux path or jump to the program buffer and read/write the gpr/csr using ld/st instructions.

[MW] I'm not quite sure what you're getting at here. Does it make sense given the clarification above?  You're right, the core will jump to the "auto-populated" bit of the program buffer to execute the instructions placed there by the *Debug Module*. This is basically the core of the "abstract command" mechanism for accessing GPRs... it's assumed that Debug Modules can do this translation themselves easily if that's how they want to do it.

2. We are thinking all the DM registers can be memory mapped so that core can write to them in the debug handler.  Can you think of any issue with that?

[MW] Are you talking abou the DM registers which are in the DMI address space? I can think of lots of issues with that, but your use case is up to you :) Not sure why you want to/need to do that. If you're talking about mapping just the Program Buffer & Data registers for the core as memory mapped, yes, that is what we do in our reference implementations.

-Megan

To unsubscribe from this group and stop receiving emails from it, send an email to debug+unsubscribe@groups.riscv.org.

To post to this group, send email to de...@groups.riscv.org.
Visit this group at https://groups.google.com/a/groups.riscv.org/group/debug/.

To view this discussion on the web visit https://groups.google.com/a/groups.riscv.org/d/msgid/debug/09b369f9-8a71-4879-8fc3-bba61ae6b6dd%40groups.riscv.org.